Blind SQL injections occur when a web application is exposed to SQL injection, but it’s HTTP responses don’t contain the results of the SQL query or any details of database errors.
In the case of a typical SQL Injection, the database error or the output of the injected malicious SQL query is directly shown in the web application and visible to the attacker.
In the exploitation of a Blind SQL Injection, attackers never see the output of the SQL queries. Still, they may see if the application or web page loads normally, and discern how long the SQL server needs to process the SQL query that an attacker passed in the user input.
Since there is no error or output from the web application, we can’t inject the UNION based injection to get the output, nor can we inject the Sub Query Injection or XPATH, which is used to get the output in the form of an error. While exploiting Blind SQL Injections, we make queries from the database and examine whether we are right or wrong.
Exploiting Blind SQL Injections is more complex and more time consuming for the attacker, but the implications and consequences for the security are similar. When an attacker executes a successful database query, they take control over the database server. This leads to data theft (e.g., credit card numbers) in addition to a complete takeover of the web server operating system using privilege escalation.
Types of Blind SQL Injections:
– Content-based Blind SQL Injection
– Time-based Blind SQL Injection
Content-based Blind SQL Injection attacks
In the case of the Content-based Blind SQL Injection, an attacker performs various SQL queries that claim the database TRUE or FALSE responses. Then the attacker observes differences between TRUE and FALSE statements.
Here is an example of an online webshop, which displays items for sale. The following link displays details about the item with ID 14, that is retrieved from a database.
The SQL query used to get this request is:
The attacker manipulates the request into:
Now, the SQL query looks like:
This results in the query returning FALSE with no items displayed in the list. The attacker then proceeds to modify the request to:
Now, the SQL query looks like:
The database will return TRUE, and the details of the item with ID 14 are displayed. This is an indication that this webpage is vulnerable.
Time-based Blind SQL Injection
In this case, the attacker performs a database time-intensive operation.
If the website does not return an immediate response, it indicates a vulnerability to Blind SQL Injection. The most popular time-intensive operation is a sleep operation.
Based on the example above, the attacker would benchmark the web server response time for a regular SQL query, and then would issue the request below:
The website is vulnerable if the response is delayed by 15 seconds.
Prevention of Blind SQL Injection
In most cases when a developer attempts to protect the website from classic SQL Injection poorly, the result is leaving space for Blind SQL Injections. Meaning if you turn off error reporting, a classic SQL Injection can become a Blind SQL Injection vulnerability.
How can you protect yourself from Blind SQL Injections:
- Use secure coding practices
Be sure to use secure coding practices, independent of the programming language. All standard web development platforms (including PHP, ASP.NET, Java, and but also Python or Ruby ) have mechanisms for avoiding SQL Injections, including Blind SQL Injections. Try to avoid dynamic SQL at all costs. The best option is to use prepared queries, also known as parameterized statements. Also, you can use stored procedures that most SQL databases support (PostgreSQL, Oracle, MySQL, MS SQL Server). Additionally, escaping or filtering special characters (such as the single quote which is used for classic SQL Injections) for all user data inputs.
- Use automated testing solutions
NeuraLegion’s solutions can detect both SQL Injection and Blind SQL injection vulnerabilities. Automatic regular scans will identify any new vulnerabilities which may not have been prevented or identified as noted above, or they may have occurred with new releases. Fully and seamlessly integrate application security testing automation into the SDLC, and empower your developers and QA to detect, prioritize and remediate security issues early, without slowing down DevOps pipeline.