The Basics and Prevention of Blind SQL Injections

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.

http://www.webshop.local/item.php?id=14

The SQL query used to get this request is:

SELECT columnName, columnName2 FROM table_name WHERE id = 14

The attacker manipulates the request into:

http://www.webshop.local/item.php?id=14 and 1=2

Now, the SQL query looks like:

SELECT columnName2 FROM tableName WHERE ID = 14 and 1=2SELECT name, description, price FROM StoreTable WHERE ID = 14 and 1=2

This results in the query returning FALSE with no items displayed in the list. The attacker then proceeds to modify the request to:

http://www.webshop.local/item.php?id=14 and 1=1

Now, the SQL query looks like:

SELECT columnName, columnName2 FROM tableName WHERE ID = 14 and 1=1SELECT

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:

http://www.webshop.local/item.php?id=14 and if(1=1, sleep(15), false)

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:

  1. 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.

  2. 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.

Get the Latest Application Security News and Content

SUBSCRIBE

Scale up efforts and set the new standard of integrating security into modern development!