Blind SQL Injection – Content-Based, Time-Based Approaches
Blind SQL Injection Overview
Blind SQL Injection(BSQL) is a type of SQL Injection (SQLI) vulnerability, where an attacker exploits the application to extract information from the database. An application vulnerable to SQLI displays application-specific information in the response when it is exploited. When an application that is vulnerable to BSQL is exploited, no information related to the application is explicitly displayed. For example, in an application vulnerable to SQLI, the responses on any request when exploited, would contain database errors, information about the database, or the content from the database. If the application is vulnerable to BSQL being exploited, the injection would happen but the information is not visible like in SQLI. An attacker would have to use the responses to the payloads by the application to infer the information.
An application scanned using Qualys WAS, that is vulnerable to BSQL injection had all the related vulnerabilities reported in QID 150012. Based on research we analyzed that splitting the BSQL-related detections based on the approach would provide more clarity to the reporting. In order to make it easier to analyze and remediate the detections, the vulnerabilities related to BSQL were split into two QIDs based on the approach used to detect the vulnerability.
BSQL injection can be detected using a couple of approaches.
- Content-based BSQL Injection
- Time-based BSQL Injection
Content-Based BSQL Injection
The WAS scanning engine uses a well-known technique in content-based approach, called True / False inference to determine if there is a blind SQL injection vulnerability. Payloads are crafted to send multiple True/False questions to the server. Based on the responses the application is determined to be vulnerable or not vulnerable. Inference based on application responses to various payloads results in the analysis of the application being vulnerable. If there is a BSQL injection vulnerability, the query with the True condition payload will cause the web application to return a different response than the False condition payload.
Examples:
True condition payload is ‘ AND 1=1
False condition payload is ‘ AND 1=2
In the web application that is being scanned, we use the true and false payloads with various inputs to determine the vulnerability. If the application has a search field that searches for a specific product and displays the results inside a table. We will append our payloads to the search parameter. Let us assume that someone searches for an item “masks”. When testing for blind SQL injection, the scanning engine sends two payloads:
True condition payload is ‘ AND 1=1
This condition is true, so available records are returned, which is the same as if the payload was the item by itself.
False condition payload is ‘ 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.
There is room for false positives reported on the application being scanned by this approach due to
- configuration of the web server
- dynamic content on the application
Based on the fact that there is room for false positives, we categorized the detections identified by this approach to be potential. A new QID 150568 which is a potential vulnerable QID has been published.
Time-Based BSQL Injection
The time-based approach is a very well-known approach as well and Qualys WAS has supported this along with the content-based approach for many years. Various payloads are sent to test and analyze the response times of the web server. If the web server reacts based on the payload, it is determined to be vulnerable. For example, a payload that introduces a sleep of 30 seconds would result in a vulnerable server not responding for 30 seconds. A server that is not vulnerable will ignore the delay introduced by the payload. The detections determined by this approach will be reported in QID 150012. There is no room for false positives in this approach so we report this QID as a confirmed vulnerability. Detections reported in 150012 that were inferred based on content will no longer be reported in 150012 QID. They will now be reported in 150568. If a customer is doing a retest or relaunching an older scan, the findings based on content from previous scans will be marked as fixed. If the vulnerability still exists in the application the detections based on content will be reported in 150568 potential QID.
Prevention of BSQL Injection
SQL(BSQLI/SQLI) injection vulnerabilities can be addressed in three areas: input validation, query creation, and database security.
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 the 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.
