SQL Injection

In this chapter, we are going to learn about SQL injection vulnerabilities.

Type of vulnerability: Server-Side

Chances to find: Common; SQLi is part of “Injection” ranked #3 in the “OWASP Top-10 Vulnerabilities“

TL;DR: A SQLi vulnerability enables an attacker to query a database in an unintended way, allowing to manipulate, add or delete data.

What is SQLi?

“A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.”  (src: OWASP)

Let’s have a look at an example. You are going to Intigriti’s super secret login page. Your user credentials are hackerman:supersecretlongpassword.

When hitting the enter button, an HTTP request would be sent to the application server, which then queries the database with the following SQL query: SELECT * FROM Users WHERE username = 'hackerman' AND password = 'supersecretlongpassword'.

An attacker could now try to inject into that SQL query to e.g. gain administrator access to the application. One way to do that would be to set the username to admin' --. This would result in a SQL query looking like this: SELECT * FROM Users WHERE username = 'admin' -- AND password = ''.

The double dash indicates that the rest of the string is interpreted as a comment. With that, the actual SQL query is just: SELECT * FROM Users WHERE username = 'admin'. This would effectively log in the attacker as the administrator user.

Impact

The impact of a successful SQL injection depends on the data that is stored in the vulnerable database. Typical attacks usually include:

  • Bypassing authentication: An attacker achieves to log in as e.g. an administrator user without having to guess the correct password.

  • Data retrieval: An attacker can download parts or all data from a database, potentially leading to a leak of sensitive data.

  • Data manipulation: An attacker can change data stored in a database to gain a benefit from faulty table entries.

  • Denial-of-Service: An attacker can delete all data leading to an application that is not usable anymore

Additional reads:

Different SQL injection types

Let’s have a look at different SQL injection types which all need a different strategy to exploit them.

Error-based SQLi

Here, the application returns an error message that reveals SQL syntax errors. An attacker can use this knowledge to further design his attack payload to successfully exploit the vulnerability.

Example write-ups:

Union-based SQLi

Here, the attacker tries to retrieve data from a different database table, other than the one, the application is normally querying. An example SQL query could look like this: SELECT product_name, product_description FROM products UNION SELECT username, password FROM users

It is important to understand that a successful UNION query only works if the datatype of all queried columns is the same (e.g. product_name = username, product_description = password) and that the amount of queried columns is equal (two in the example).

Blind SQLi

Here, the attacker receives no direct feedback from the application (as in seeing the database output in the web app). In order to obtain valuable insights, he needs to monitor the applications’ response by using one of two tactics:

  • Boolean-based: If the application shows any difference whether a SQL query was correct or incorrect (e.g. by listing some products or none at all), an attacker can try to use a boolean-based query. Here, the SUBSTRING sql query syntax is used to retrieve data letter-by-letter.

  • Time-based: Using delays, an attacker can try to retrieve one letter at a time of a certain table / column by monitoring the time it takes to send the server response.

Both approaches need an attacker to write an individualized script scraping data letter-by-letter. Blind SQLi vulnerabilities are the most time-consuming out of all categories.

Last but not least, you could also try to use the most common automated tool for SQLi vulnerabilities called SQLMap. Make sure to be cautious, as this tool can easily break an application. Make sure to understand the tool’s functionality first.

Additional reading material:

How to prevent SQLi?

There are well-established and secure mechanisms to prevent against SQLi:

Additional prevention techniques (defense-in-depth techniques) include the reduction of the database user rights to the bare minimum.

More in-depth information can be found in OWASP’s SQLi prevention cheet sheat.

Additional resources:

Let’s have a look at a video example of a SQL Injection vulnerability:

Let’s have a look at UNION attack payload:

Now, let’s learn how we can inspect the database, so that we don’t have to act blindly:

Last but not least, we are going to look into time-based blind SQL injections:

The following links are valuable to learn more about SQL Injection: