Intro

Our goal here is to explain what SQL Injection means, how it works, and what types of SQLi exist. With so many applications talking on the internet, while also having some sort of database on the backend, SQL Injection is something you should always think of.

There’s too many production systems that are internet-facing, and if they have a database on their backend (which they usually do), you would probably want to mitigate this risk in any way possible.

What is SQL Injection?

SQLi, or short for SQL Injection is an attack on a database of a webapp. SQL Injection means that the malicious query gets executed – injected. This happens when we don’t validate properly, not sanitizing our user inputs, or not using stored procedures, for example. When we don’t do this, we allow the user input to be sent from their browser – or our webapp’s frontend – to the backend of the app, where the database lives, which then gets executed. The idea here is to have some sort of control, so that our app will evaluate the given input to see if it’s valid, before letting the query be executed. Ideally, if the input is not valid, it would just not let the user execute. If we don’t do this, we will be vulnerable to the SQL injection.

When this attack is successful, there’s a risk of stuff within the webapp database being deleted, altered, stolen, or used to further attack other areas of the application. SQL injection, even though its one of the oldest vulnerabilities, as you can infer, can be particularly devastating for us.

Let’s try and briefly illustrate how an SQL injection would look like, using one of the simplest types of SQL injection – in-band SQLi.

For example, imagine the query below should return personal data of the current user – call him user1, and display it:

SELECT * FROM users WHERE user_id LIKE ‘user1’

If we allow this query to be executed in our app, our attacker could simply say %’– which would in turn send the following query to our database:

SELECT * FROM users WHERE user_id LIKE ‘%’--’

Since in SQL the two dashes are used to comment out the rest of the line that follows, our app would actually execute the following query:

SELECT * FROM users WHERE user_id ‘%’

The percent sign in SQL is a wildcard, and the query above, when executed, would in turn display all the contents in the users table.

This is quite scary as you can see, and not at all complex to do. The example above is something that’s known as in-band SQLi.

Types of SQLi

There are three main categories of SQLi: in-band SQLi, blind SQLi, and out-of-band SQLi. Our example above used the in-band SQLi, but let’s try and explain these three types of SQLi a bit more.

In-band SQLi

This is the simplest of the three SQLi types; in-band means that our attacker, who is able to change the query to their liking, will get direct results of this changed query. Direct results implies they also get their results in the same way they performed the attack – if they did that with their browser, their browser would also display the results of the query.

Subcategories include error-based SQLi and union-based SQLi.

Blind SQLi

Contrary to the in-band SQLi, with blind SQLi we get no feedback, or very little response as to the success of the injected query. One of the most well known examples of the blind SQLi is the ‘ OR 1=1;– (which is also a subcategory of blind SQLi called Boolean SQLi). 1=1 is always a true statement, and when combined with the OR operator, this query will also be true, which can end up being enough for the logic of our web application that would in turn believe that it found a valid username/password combination, thus allowing access.

This can be used to bypass authentication – letting us through the login screen; login forms that are connected to the user database are often made in such a way that the application doesn’t really care what username/password is given to it, rather that the two are matched successfully in the respective table.

You can think of it as our application asking the database if there is such a combination of the username/password (not what the contents are) and the response from the database is either true or false. If true, we are granted access, and can login successfully.

Blind SQLi query could look something like this:

SELECT * FROM users WHERE username=’ ‘ and password=’ ‘ OR 1=1;

Two subcategories include: Boolean-based SQLi and time-based SQLi

Out-of-band SQLi

Not that commonly used, out-of-band SQLi needs specific features to be enabled on the database server, or in the web application’s logic, that would make an external network call based on the results of the given query.

The server would need to have commands that could trigger DNS or HTTP requests, otherwise we can’t do the out-of-band SQLi.

Further, there are two communication channels in out-of-band SQLi – one that is used to do the attack, and the other that would collect the results.

If, however, these conditions are met, what would happen is that the attacker could make a request to the website, with their payload, then the website/app would make an SQL query on their behalf, which gets passed to the database (the payload is passed too), and finally, the payload has a request inside it that forces the database to send back an HTTP request to the attacker’s machine – containing the results.

Preventing SQLi

Some of the best ways to prevent SQLi is to use, prepared statements (parametrized queries), input validation, and escaping user input.

Prepared statements (parameterized queries) – the only fully effective way to prevent all types of SQLi in web apps. (If your language doesn’t support parameterized queries but your database does, you can use stored procedures instead).

We must note that even though input validation and escaping user input can help you against SQLi, these methods are not completely bulletproof and the attacker might still find a way around them.

Conclusion

We hope that this short primer on SQLi has brought the topic closer to you. The main takeaway here (we feel) is the fact that avoiding this specific vulnerability should mostly depend on your developers, specifically, crafting the appropriate prepared statements/parameterized queries as this is the best approach – since it eliminates the vulnerability alltogether. Without it, your filters, blacklisting, or other controls, are just bigger obstacles, but not the full solution.

#SQLi #blind #in-band #out-of-band