QID 150568
Date Published: 2023-01-12
QID 150568: Content-based Blind SQL Injection
Blind SQL injection is a specialized type of SQL injection that enables an attacker to modify the syntax of a SQL query in order to retrieve, corrupt, or delete data. A successful exploit manipulates the query's logic. Queries created by concatenating strings with SQL syntax and user-supplied data are prone to this vulnerability. When any part of the string concatenation can be modified, an attacker has the ability to change the meaning of the query.
Typical detection techniques for SQL injection vulnerabilities use a payload that attempts to produce an SQL error from the web application. Detection based on blind SQL injection uses inference based on the differences among the application's responses to various payloads. Blind SQL does not rely on error messages, which is beneficial when testing web applications that trap errors.
The WAS scanning engine uses a well-known technique called True / False inference to determine if there is a blind SQL injection vulnerability. Basically, it uses two payloads: one with a True condition and another with a False condition. If there is a blind SQL injection vulnerability, the query with the True condition payload will cause the web application to return a different response than the False condition payload.
A good example of a True condition payload is ' AND 1=1 (since 1 always equals 1, the condition is true). An example of a False condition payload is ' AND 1=2 (since 1 does not equal 2, the condition is false).
Say there is a web application with an input that searches customer first names and displays the results inside a table. Assume that if someone searches for John there is one result only. When scanning for blind SQL injection, the scanning engine sends two payloads:
- True condition payload: John' AND 1=1
This condition is true, so one record is returned and the output is John, which is the same as if the payload was the name John by itself.
- False condition payload: John' AND 1=2
The condition is false, so no records are returned and the output is nothing or a message such as No Results Found.
Seeing the difference in results, the scanning engine draws the conclusion that there is a blind SQL injection vulnerability.
For vulnerabilities that would be flagged based on time based approach refer to 150012
The scope of a SQL injection exploit varies greatly. If any SQL statement can be injected into the query, then the attacker has the equivalent access of a database administrator. This access could lead to theft of data, malicious corruption of data, or deletion of data.
All input received from the client side should be validated for correct content. If a value's type or content range is known beforehand, then stricter filters should be applied. For example, an email address should be in a specific format and only contain characters that make it a valid address; or numeric fields like a USA zip code should be limited to five digit values.
Prepared statements (also referred to as parameterized queries) provide strong protection from SQL injection. Prepared statements are precompiled SQL queries whose parameters can be modified when the query is executed. Prepared statements enforce the logic of the query and will fail if the query cannot be compiled correctly. Programming languages that support prepared statements provide specific functions for creating queries. These functions are more secure than string concatenation for assigning user-supplied data to a query.
Stored procedures are precompiled queries that reside in the database. Like prepared statements, they also enforce separation of query data and logic. SQL statements that call stored procedures should not be created via string concatenation, otherwise their security benefits are negated.
SQL injection exploits can be mitigated by the use of Access Control Lists or role-based access within the database. For example, a read-only account would prevent an attacker from modifying data, but would not prevent the user from viewing unauthorized data. Table and row-based access controls potentially minimize the scope of a compromise, but they do not prevent exploits.
For more information, see the OWASP SQL Injection Prevention Cheat Sheet.
CVEs related to QID 150568
| Advisory ID | Software | Component | Link |
|---|