API Sécurité 101: Injection – Boulevard de la sécurité

0


[ad_1]

How SQL injection and command injection happen in APIs

photo by Ivan Diaz to Unsplash

You’ve probably heard of the top ten in OWASP or the top ten vulnerabilities that threaten web applications. OWASP also periodically selects a list of the top ten vulnerabilities that threaten APIs, referred to as the top ten in the OWASP API. The top ten current APIs are Authorization at broken object level, User authentication interrupted, Excessive data exposure, Lack of resources and flow limitation, Function level authorization interrupted, Mass assignment, Incorrect security configuration, Injection, Poor asset management, and Insufficient logging and monitoring. These are the vulnerabilities that affect APIs the most. Today, let’s talk about OWASP API # 8, injections, a type of vulnerability that affects most applications and API systems.

Injection is the underlying issue for many vulnerabilities, such as SQL injection, OS command injection, and XML injection. Together, injections represent a huge percentage of vulnerabilities found in real-world applications and APIs.

How the injections are done

In a single sentence, injection occurs when an application cannot properly distinguish between user data and untrusted code.

Untrusted user data can be HTTP request parameters, HTTP headers, and cookies. They can also come from databases or stored files that can be modified by the user. If the application does not properly process unreliable user data before inserting it into a command or query, the program’s interpreter will confuse user input as part of a command or query. In this case, attackers can send data to an application in a way that will alter the meaning of its commands.

In an SQL injection attack, for example, the attacker injects data to manipulate SQL commands. And in a command injection attack, the attacker injects data that manipulates the operating system’s command logic on the hosting server. Any program that combines user data with commands or programming code is potentially vulnerable.

Injection vulnerabilities can also affect API systems, as an API is just another way untrusted user input can enter an application. Let’s take a look at how injection vulnerabilities appear in an API.

Example 1: Retrieving blog posts

Let’s say an API allows its users to fetch blog posts by sending a GET request like this:

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

This request will cause the API to return message 12358. The server will retrieve the corresponding blog post from the database with an SQL query, where post_id refers to the identifier transmitted by the user via the URL.

SELECT * FROM posts WHERE post_id = 12358

Now what if the user requests it from the API endpoint instead?

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

The SQL server would interpret the part of the identifier after the semicolon as a separate SQL command. So the SQL engine will first run this command to retrieve the blog post as usual:

SELECT * FROM posts WHERE post_id = 12358;

Then it will run this command to drop the users table, causing the application to lose the data stored in that table.

DROP TABLE users

This is called an SQL injection attack and can occur whenever user input is passed in dangerous SQL queries. Note that user input into an API doesn’t just pass through URL parameters, it can also reach the application through POST requests, URL path parameters, etc. It is therefore important to secure these places as well.

Example # 2: Reading system files

Let’s say the site allows users to play the files they downloaded through an API endpoint:

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

This request will cause the server to retrieve the user’s files via a system command:

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

In this case, a user could inject new commands into the operating system’s system command by adding additional commands after a semicolon.

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

This command will force the server to delete the folder located in / var / www / html / users, where the application stores user information.

rm -rf /var/www/html/users

Prevention of injection vulnerabilities in APIs

These are simplified examples of injection vulnerabilities. In reality, it’s important to remember that injection vulnerabilities aren’t always so obvious. And this manipulation can happen every time that data is processed or used. Even though the malicious user data is not immediately used by the application, the untrusted data can eventually move somewhere in the program where it can do something wrong, such as an unsafe function or an unprotected request. And this is where they cause damage to the app, its data or its users.

This is why injections are so difficult to avoid. Untrusted data can attack any application component it touches in the stream. And for every unreliable data the application receives, it must detect and neutralize attacks targeting every part of the application. And the application may think a piece of data is safe because it does not contain any special characters used to trigger XSS when the attacker intends to trigger an SQL injection instead. It is not always easy to determine which data is safe and which is not, as safe and dangerous data looks very different in different parts of the application.

Validation of entries

So how do you protect yourself against these threats? The first thing you can do is validate the unreliable data. This means that you are implementing either a block list reject any entry containing dangerous characters that may affect the components of the application. Or you implement a authorization list which only allows input strings with known good characters. For example, let’s say you are implementing a signup functionality. Since you know the data is going to be inserted into an SQL query, you reject any user name entry that contains special SQL characters, such as the single quote. Or, you can implement a rule that only allows alphanumeric characters.

But sometimes blocklists are hard to do because you don’t always know which characters will be important to app components down the line. If you just miss a special character, it can allow attackers to bypass protection.

And permission lists can be too restrictive, and in some cases you will sometimes need to accept special characters such as single quotes in user input fields. For example, if a user named Conan O’Brien signs up, they should be allowed to use a single quote in their name.

Settings

Another possible defense against injection is parameterization. Parameter setting refers to the compilation of the code part of a command before the insertion of the parameters supplied by the user.

This means that instead of concatenating user input into program commands and sending it to the server for compilation, you first define all the logic, compile it, and then insert user input into the command just before it. execution. Once user input is inserted into the final command, the command will not be parsed and compiled again. And anything that was not in the original statement will be treated as string data and not as executable code. Thus, the logical part of the program of your order will remain intact.

This allows the database to distinguish between the code part and the data part of the order, regardless of what the user input looks like. This method is very effective in preventing certain injection vulnerabilities, but cannot be used in all code contexts.

Escape

And finally, you can escape special characters instead. Escaping means that you encode special characters in user input so that they are treated as data and not as special characters. By using special markers and syntax for marking special characters in user input, escaping lets the interpreter know that the data is not meant to be executed.

But this method also has its problems. On the one hand, you must use the exact encoding syntax for each downstream parser or risk encoded values ​​being misinterpreted by a parser. You can also forget to escape certain characters, which attackers can use to neutralize your encoding attempts. So, a key to preventing injection vulnerabilities is understanding how analyzers for different languages ​​work and which analyzers run first in your processes.

What other security concepts would you like to know? I would like to know. Do not hesitate to connect on Twitter @ vickieli7.

Want to learn more about application security? Take our top ten free OWASP courses here: https://www.shiftleft.io/learn/.


API 101 Safety: Injection was originally published in ShiftLeft Blog on Medium, where people continue the conversation by highlighting and responding to this story.

*** This is a Syndicated Security Bloggers Network blog by ShiftLeft Blog – Medium written by Vickie Li. Read original post on: https://blog.shiftleft.io/api-security-101-injection-a7feea1d4fd?source=rss—-86a4f941c7da—4


[ad_2]

Leave A Reply

Your email address will not be published.