Breaking Down SQL Injection: Unveiling the Attack Types

SQL databases are quite old technology that are still heavily used today. However, despite their popularity, they are susceptible to a well-known vulnerability known as SQL injection. This vulnerability is included in the latest top 10 OWASP vulnerabilities 2021, within the “injection” category.

In a recent article, we have covered the basics of SQL and we also have another article talking about how SQL injection works. Albeit not explicitly stated, the article covers the In-Band SQL injection. Now we will focus on the types of SQL injection.

Types of SQL Injection

In the real world, there are a wide variety of SQL injection attacks based on how the vulnerabilities can be exploited based on different situations. However, it is often classified under three main categories based on how the results are retrieved.

In-Band SQL Injection

This is the most basic type of SQL injection and the easiest one to detect and exploit. SQL injection. In the case of In-Band SQL injection attack, an attacker might be able to inject malicious SQL statements into an input or query parameters.

Error-Based

When trying to inject the SQL statements, sometimes the application with the SQL vulnerability in it can be identified by the errors. In an error-based SQLi attack, an attacker injects SQL statements that intentionally cause the application to generate these errors. By analyzing the error messages, an attacker can gain information about the database structure or extract data.

UNION-Based

In SQL, UNION is a statement used to combine two or more SELECT statements into the existing table. By injecting malicious SQL statements that include a UNION statement, an attacker can retrieve data from other database tables or extract sensitive information.

In a web application, the database is used to present a particular data or information to the user. In this scenario, the data being presented is often dynamically changing, meaning that it gets affected and changed by the user input. The idea behind this is, the data needs to be somehow manipulated so it presents another sensitive data belonging to another table in the database which is not supposed to. It can be achieved by utilizing the UNION statement. If you are curious, we also have covered this in an article explaining [how the UNION statement works](https://www.binaryte.com/blog/dive-into-sql- exploring-the-foundations).

Exploiting the blind SQL injection can be quite difficult. This is due to the fact that the attacker may not be able to see the results to check whether the injected query is working or not. In the case of blind SQL, the error messages have been disabled, making it harder to conduct the attack.

Authentication Bypass

Quite often, the web application stores the users’ credentials like username and password in the database.To check if the users’ is registered or not, it often uses a login form which is connected to the database containing these values. If users need to authenticate themselves, they need to provide their username and password.

Exploiting this vulnerability is relatively straightforward, so let us explain the underlying logic.

Say that Bob wants to login to a web application, example.com. His registered username is “bob123” and his password is “pa$$w0rd”. Bob fills out the login form with this credential and sends the request to the server. In the database server, both values are then checked if the provided username matches the password. If both matches, the web application will return a true value and let the users proceed. If not, Bob won’t be allowed to authenticate himself to the corresponding web.

When translating the logic into an SQL query, it would typically resemble the following representation.

SELECT * FROM <table_name> WHERE username=”bob123” AND password=”pa$$w0rd”;

As you can see, each value will be placed in the corresponding field. If not handled properly,
the attackers might be able to manipulate the logic. Assume the attacker has Bob’s username. Since the objective is getting the return value of true to proceed, the attackers can change the username to bob123” OR 1=1 ;— and send any password like 12345. So the query will now look like this.

SELECT * FROM <table_name> WHERE username=”bob123” OR 1=1 ; --” AND password=”12345”;

Because 1=1 is always true, and false (username=””) or true (1=1) returns true, the final result is true. The semicolon (;) will tell the database that the query has ended and the double dash sequence (—) will comment out everything that comes after this so it will be ignored. Hence, the objective is achieved.

Boolean-Based

This type of SQLi relies on exploiting the application’s behavior based on Boolean (true/false) conditions. The database will check if an input is valid with the true/false response which is often shown without any additional or supporting information. Since the database checks the input, the attacker might get an idea whether the injected SQL statement is working.

At first glance, you might assume that this brief response lacks sufficient information. However, surprisingly, by analyzing just these two responses, it is actually feasible to systematically determine the complete structure and contents of a database.

Time-Based

The time based SQL injection is very similar to Boolean-based. This type of SQLi relies on delaying the application’s response to extract information. Unlike the Boolean based, in which the returning Boolean value is visible, it usually has no visual indicator at all. By injecting SQL statements that cause the application to wait for a specific amount of time, an attacker can decide whether a returning value is true or false.

Out of Band

In certain scenarios where direct communication with the attacker is possible, out-of-band SQLi attacks can be employed. These attacks leverage techniques such as DNS queries or HTTP requests to extract data from the database.

Conclusion

In conclusion, understanding the various types of SQL injection vulnerabilities is crucial for web application developers and security professionals alike. By recognizing the diverse attack vectors of SQL injection, we can better prepare against these malicious exploits. Implementing robust security measures, such as input validation, parameterized queries, and strict access controls, is paramount to mitigate the risks associated with SQL injection attacks.