OWASP API and Injection Dangers

Wed Jul 06 2022
OWASP API and Injection Dangers

OWASP API is a security project created by OWASP that aims to focus on strategies and solutions to mitigate security vulnerabilities in application programming interfaces (APIs). Threats from OWASP API will cause businesses to leak customer information, and transaction information, take control, and even lose control of the website if the attack is subtle. Which, malicious code Injection is a type of vulnerability affecting most applications and application programming interface systems. The injection is the underlying problem in terms of several vulnerabilities like SQL Injection, XML Injection, etc. These injections account for a large proportion of the vulnerabilities found in real-world APIs and applications.

List of 10 OWASP API Vulnerabilities Updated in 2021

  1. Broken Access Control (Broken Access Control)
  2. Cryptographic Failures
  3. Injection
  4. Insecure Design
  5. Security Misconfiguration
  6. Vulnerable and Outdated Components
  7. Identity and Authentication Failures
  8. Software and Data Integrity Failures
  9. Security Logging and Monitoring Failures
  10. Server-Side Request Forgery

How Injection works in OWASP API

How Injection works in OWASP API

Untrusted user data can be HTTP application layer protocol request parameters, HTTP headers, and cookies. These data can also come from a database or archive that the user uses to modify. If the web application does not thoroughly process the data received from the untrusted user file in advance but instead inserts commands or queries, the interpreter. From there, attackers could take advantage of this vulnerability to send data to enterprise web applications based on the vulnerability.

In a SQL Injection attack, the attacker injects malicious code to manipulate SQL commands, and in a Command Injection attack, the attacker injects data that controls the logic of operating system commands on the server. storage.

Injection vulnerabilities can also affect the API system where the API is just another way that users input data into the application. Let's see how security holes appear in the API.

Example 1: Retrieve API blog posts

An API that allows users to retrieve blog posts by sending a GET request like this:

GET /api/v1.1/posts?id=12358

The request will cause the API to return post 12358. The server will automatically retrieve the corresponding blog post from the database using an SQL query, where post_id refers to the id passed by the user in the URL.

SELECT * FROM posts WHERE post_id = 12358

Now, what if the user requests from the API endpoint?

GET /api/v1.1/posts?id=12358; DROP TABLE users

SQL Server will parse the id after the semicolon as a separate SQL command. From there, the SQL engine will first execute the command line to retrieve the blog post as usual:

SELECT * FROM posts WHERE post_id = 12358;

Finally, the Injection will execute a command to delete the user table causing the data to be lost in that table


Example 2: Read system files

If the site allows users to read the files they've uploaded through the API endpoint:

GET /api/v1.1/files?id=1123581321

Upon receiving the request, the server retrieves the command entered by the user via the system command:

cat /var/www/html/users/tmp/1123581321

The user can now include new commands in the operating system command by adding the command after the semicolon:

GET /api/v1.1/files?id=1123581321; rm -rf /var/www/html/users

This command will force the server to delete the directory located at var/www/html/users, this is where the application stores user information.

rm -rf /var/www/html/users

Prevent security vulnerabilities from OWASP API

The above examples will help businesses understand Injection vulnerabilities more simply. Injection vulnerabilities are very sophisticated and OWASP API attacks can occur at any time while data is being processed or used.

When user data is judged to be malicious, the server will not use it but will check and roll it back. But for data with the untrusted state that can move in the database can go anywhere, can be accessed at any location, and used to inject malicious code.

This is why injection codes are so hard to prevent. Untrusted data can attack any component of the application. And for every piece of untrusted data an application receives, it must detect and neutralize attacks that target every part of the application. And the application may think that data is safe because it does not contain any special characters used for XSS when the attacker intends to insert SQL. It is not always easy to determine what data is safe and what is not, as safe and unsafe data vary widely in different parts of the application.

Input validation method

To combat Injection, businesses can validate all untrusted data by creating a block list implement that rejects any input containing dangerous characters.

In addition, enterprises can implement lists only for inputs with safe allowed characters. Example: With registration functionality being implemented. Webmasters will be aware of the data inserted into an SQL query, they can reject any input containing SQL characters (such as commas or quotes).

The downside of this approach is that block lists are challenging to implement because businesses do not always know which characters are dangerous or which are important for application parts. In addition, this measure is limited to the k block list, and sometimes special characters must also be accepted such as the name Conan O'Brien when this person registers.

The special character encoding method

By using special marks and syntax to mark as user input, let the interpreter know what data should not be executed.

The downside of this approach is that the business must use the correct keycode syntax for every parser or the programmer may forget some characters, creating an opportunity for attackers to disable coding efforts.

Parameterization method

Parameterization involves compiling the code portion of the directive before inserting any user-supplied parameters. Instead of concatenating program instructions and sending them to the server to be compiled, administrators must pre-define the logic, compile, and insert. After the code header is inserted into the last command, the directive will not be parsed and recompiled. Therefore, the logit portion of the command remains intact, allowing the database to distinguish between the code and the command data in all user cases. The downside of this approach is that it cannot be used flexibly in the code context.

Use a security measure

In addition to the measures such as parameterization, input validation, and character encoding listed above. Using a security measure such as a cloud-based web application firewall (Cloud WAF) from a current security solution like VNIS (VNETWORK Internet Security) will help businesses stay safe from malicious code injection.

VNIS smart web application firewall also helps businesses solve the top 10 latest OWASP vulnerabilities with Cloud WAF, with the ability to customize XSS, SQL of Cloud WAF, and Generic Injection rule set to help businesses OWASP Injection Attack Prevention Industry. VNIS's intelligent WAF integration makes bot protection and API management tighter.

Cloud WAF is also located in many countries, improving security for businesses at Layer 7 (application layer) when Internet providers often ignore it (only focusing on Layer 3 and Layer 4). . Cloud WAF also enhances the ability to analyze and remove malicious traffic such as DDoS and the vulnerabilities are eliminated thanks to the Scrubbing Center system.

To answer questions related to website security or prevent injection attacks from the top 10 OWASP, please contact the hotline (028) 7306 8789 or fill in the registration information below, so we can contact and advise you as soon as possible.

Please leave your contact information, and our experts will contact you soon.

[First Name] is required field
[Email Address] is required field
[Phone Number] is required field
[Content] is required field
News All