Common Attack Pattern Enumeration and Classification
A Community Resource for Identifying and Understanding Attacks
Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the adversary constructs input strings that probe the target through simple Boolean SQL expressions. The adversary can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the adversary determines how and where the target is vulnerable to SQL Injection.
An adversary may try entering something like "username' AND 1=1; --" in an input field. If the result is the same as when the adversary entered "username" in the field, then the adversary knows that the application is vulnerable to SQL Injection. The adversary can then ask yes/no questions from the database server to extract information from it. For example, the adversary can extract table names from a database using the following types of queries:
"username' AND ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 108".
If the above query executes properly, then the adversary knows that the first character in a table name in the database is a letter between m and z. If it doesn't, then the adversary knows that the character must be between a and l (assuming of course that table names only contain alphabetic characters). By performing a binary search on all character positions, the adversary can determine all table names in the database. Subsequently, the adversary may execute an actual attack and send something like:
"username'; DROP TABLE trades; --
In the PHP application TimeSheet 1.1, an adversary can successfully retrieve username and password hashes from the database using Blind SQL Injection. If the adversary is aware of the local path structure, the adversary can also remotely execute arbitrary code and write the output of the injected queries to the local path. Blind SQL Injection is possible since the application does not properly sanitize the $_POST['username'] variable in the login.php file.
Skill or Knowledge Level: Medium
Determining the database type and version, as well as the right number and type of parameters to the query being injected in the absence of error messages requires greater skill than reverse-engineering database error messages.
In order to determine the right syntax for the query to inject, the attacker tries to determine the right number of parameters to the query and their types. This is achieved by formulating conditions that result in a true/false answer from the database. If the logical condition is true, the database will execute the rest of the query. If not, a custom error page or a default page is returned. Another approach is to ask such true/false questions of the database and note the response times to a query with a logically true condition and one with a false condition.
The only indicators of successful Blind SQL Injection are the application or database logs that show similar queries with slightly differing logical conditions that increase in complexity over time. However, this requires extensive logging as well as knowledge of the queries that can be used to perform such injection and return meaningful information from the database.
Security by Obscurity is not a solution to preventing SQL Injection. Rather than suppress error messages and exceptions, the application must handle them gracefully, returning either a custom error page or redirecting the user to a default page, without revealing any information about the database or the application internals.
Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as SQL content. Keywords such as UNION, SELECT or INSERT must be filtered in addition to characters such as a single-quote(') or SQL-comments (--) based on the context in which they appear.
The injected SQL statements are such that they result in a true/false query to the database. If the database evaluates a statement to be logically true, it responds with the requested data. If the condition is evaluated to be logically false, an error is returned. The adversary modifies the Boolean condition each time to gain information from the database.
Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application or the database.
Special characters in user-controllable input must be escaped before use by the application.
Employ application-level safeguards to filter data and handle exceptions gracefully.
[R.7.1] [REF-3] "Common Weakness Enumeration (CWE)". CWE-20 - Input Validation. Draft. The MITRE Corporation. 2007. <http://cwe.mitre.org/data/definitions/20.html>.
More information is available — Please select a different filter.