Blind SQL Injection — Threat or Child's Play?

One of the primary issues in the database world is SQL injection - it's prevalent to such an extent that even OWASP continuously lists it as the #1 threat targeting web applications. SQL injection can have many types, and one of these types is blind SQL injection - in this blog post, we will go through just how harmful such an attack can be.

What Is SQL Injection? What Are Its Categories?

SQL injection is the main attack directed at databases - an application is vulnerable to SQL injection when an input provided by a user is forwarded straight into a database without being sanitized and properly dealt with.

The categories of SQL injection are very important to understand because of a couple of key reasons:

• Different types of SQL injection impact web applications in different ways.
• Some types of SQL injection can be more easily prevented than others.
• Some types of SQL injection depend directly on the features of our web applications (e.g., the results of a successful blind SQL injection attack are directly dependent on whether our web application is displaying errors or not.)
• Some types of SQL injection attacks have sub-types (think time-based blind SQL injection) - these sub-types might make or break a deal for a nefarious party as well because they're directly dependent on a specific factor that, in this case, cannot be controlled, and so they're direct - time.

SQL injection has a couple of categories:

The Kingdom of Blind SQL Injection

Think of your application as a castle. We know this might seem at least a little bit odd but bear with us. Now, imagine your web application as a castle. Done? Okay, imagine that a bunch of blind soldiers with spears are attacking it and their spears frequently miss the fortified defenses of the castle. What do you think - how much time do the blind soldiers with spears have to spare to be done with your castle's defenses? It will take a while, but the soldiers will eventually get through. That's true - and once the soldiers get through, the treasures you store in your castle (the data inside of your web applications) are cactus - they will steal everything.

Soldiers are well-equipped, and even though they are blind, they will eventually perpetrate your defenses - oh, noes! That's pretty much how blind SQL injection works in the real world, so let us give you another example:

1. An attacker finds your web application to be vulnerable to a blind form of SQL injection by adding a single quote after a certain parameter - then your web application returns an error.
2. An attacker keeps crafting SQL queries - none of them return any error. However, he quickly finds that if he executes one type of query, the data inside of your web application shows on the screen, after he executes another - the data disappears. "Aha!", - thinks the attacker. "Gotcha. Got a blind SQL injection flaw."

As you might already notice, a blind SQL injection is an attack that asks the database "questions" in a form of queries and tries to determine whether they are true or false based on the response on the web application. Blind SQL injection is most frequently detected by running queries like so:

If a web application returns a "positive" response (meaning that it returns a visible difference on a web page), the web application is susceptible to such an attack, while if an application is indifferent, it is probably not. In the first scenario, the attacker will know something's up with your database and try to penetrate your defenses even further. And so the game begins - the attacker is trying to notice what kind of responses your web application is willing to return. A query returns a page with results - OK, they probe further, a query returns a blank page - hmmm... they change the query and try again. And so the game continues until all data that interests a nefarious party is extracted from your database. Yes, such kind of querying will take a long time (and that's one of the things blind SQL injection is mostly known for), but keep in mind that time, as sad as it might be, probably won't stop an attacker that has an aim to harm your systems as much as possible or steal all of your data.

Some web applications might even filter the parts in GET or POST parameters meaning that they might "catch" single or double quotes being used, but that's only one piece of the puzzle. Such a function is frequently a part of a web application firewall type of functionality - we have already discussed WAFs (short for Web Application Firewalls) in another article of ours, so we won't go too much into detail, but keep in mind that web application firewalls deflect all kinds of attacks ranging from Denial of Service to, you guessed it, SQL injection. 

Types of Blind SQL Injection

There are two types of blind SQL injection - boolean-based and time-based. Boolean-based blind SQL injection is reliant on sending a certain SQL query to the database to determine whether the query returns a TRUE or FALSE result by looking at the response of the application, while time-based SQL injection is reliant on time - a query probing a web application for blind time-based SQL injection will force the database to wait a couple of seconds before returning a response, and if the response is returned after the exact amount of specified seconds has passed, the attacker will be able to determine that the application is susceptible to blind, time-based SQL injection. Here are a couple of key differences and similarities between the two types:

Protecting Against Blind SQL Injection

Protecting from a blind type of SQL injection, contrary to popular belief, does not take much skill or effort - it can be prevented using basic security measures. Yes, it's as simple as that! We can accomplish that by using Prepared Data Objects (PDO) in PHP (they split the input provided by the user and the rest of the query, thus any kind of SQL injection is not possible) by using automated testing solutions that inform us whether or not our application is susceptible to SQLi, or, of course, using whitelist security controls - we, as developers, should have a habit of filtering and sanitizing every kind of parameter that somehow interacts with our data. By doing that , we can put our web applications at the next security level both by protecting against all kinds of SQL injection attacks and other types of security issues.

Once we put our web applications at the next level of security, we must take care of the security of our own accounts too - we can run a search through BreachDirectory to see if any of our accounts are at risk and act according to the advice given to us. Once we do that, our accounts should be secure as well. Win-win!

Blind SQL injection is a type of SQL injection where an attacker cannot figure out how our web applications "think", so instead, he or she has to rely on the output a web application gives us or rely on time, depending on which method (boolean-based or time-based) is in use. When relying on boolean-based SQL injection, an attacker counts on the fact that the web application might look different than usual, while when using time-based SQL injection, the attacker heavily relies on time.

No matter what type of SQL injection is elected to use by the attacker, no type provides the attacker with a quick way to gain data - an attacker may literally spend hours, days, or even months gaining data of interest to him, but once the attack is successfully accomplished, it will usually be sold on the dark web for thousands of dollars to other nefarious parties, and the cycle will continue.

To protect against blind SQL injection, make sure to employ secure coding practices, do not forward user input straight into a database, and refine how errors are returned in your web applications.

Additionally, make sure to run a search through known data breach search engines to ensure that your data is safe both during the day and the night and until the next time. See you in the next blog!