How to Prevent Blind SQL Injections: The Basics

Blind SQL Injections are a subtype of SQL Injection vulnerabilities. Exploiting Blind SQL Injections is more difficult and more time consuming for the attacker but the consequences to web application security are similar. Successful exploitation of the database query language gives the attacker control over the database server. This, in turn, may lead to sensitive data theft (for example, credit card numbers) and even complete web server operating system takeover using privilege escalation.

In the case of a classic SQL Injection, the attacker may see a database error or directly see the output of their injected malicious SQL commands in the web application. In the case of a Blind SQL Injection, they never see the output of the SQL statements but they can see if the application or page loads correctly and see how long it takes for the SQL server to process the SQL query that they pass in the user input.

There are two types of Blind SQL Injections: Content-based Blind SQL Injection and Time-based Blind SQL Injection. In the case of the Content-based Blind SQLi, the attacker analyzes whether the user-supplied input causes the page to load differently. In the case of Time-based Blind SQLi, the attacker injects an SQL command that caused a delay (for example, SLEEP) and sees if the page is displayed with the delay.

Prevention Techniques

Techniques that you should use to prevent Blind SQL injections are the same ones that you should use to prevent any SQL Injections. Very often, a Blind SQL Injection is a result of the developer trying to protect the website badly against SQL Injections in general. For example, if you turn off error reporting, a classic SQL Injection vulnerability can become a Blind SQL Injection vulnerability.

To protect yourself:

• Use secure coding practices, independent on the language. All common web development platforms (including of course PHP, Java, and ASP.NET but also Ruby or Python) have mechanisms that you can use to avoid SQL Injection vulnerabilities including Blind SQL Injections. Avoid dynamic SQL at all costs. The best choice is to use prepared statements also known as parameterized queries. You can also use stored procedures if your SQL database supports them (most databases do, for example, MySQL, Oracle, MS SQL Server, PostgreSQL). Additionally, you may filter and escape special characters (such as the single quote used for basic SQL Injections) for all input fields and other user data inputs. Filtering and escaping on its own, however, is not enough.
• Use a vulnerability scanner that can detect both SQL Injection and Blind SQL injection vulnerabilities. Run regular scans to identify any new bugs which may not have been identified or prevented as per the above or that may be introduced moving forward. Include the security scan in your software development lifecycle (SDLC) so that vulnerabilities are caught as early as possible.