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?
As we have already told you in some of our earlier blog posts, 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 dependant 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 directly – time.
SQL injection has a couple of categories:
| SQL Injection Category | About |
|---|---|
| Classic SQL injection | The most prevalent SQL injection type. Such an injection type is most frequently detected (and most famously depicted by script kiddies as being “very simple to use”) by adding a single-quote sign to a GET parameter that is then evaluated by a database. |
| Out-of-band SQL injection | Such a type of SQL injection that can be detected using OOB (out-of-band) techniques – functions that might help detect such a type of injection include xp_dirtree (a function that lets us list all of the directories in a folder) and similar. |
| Blind SQL injection | Such a type of SQL injection where an application does not return any errors – as such, an attacker is not able to determine whether his or her malicious query was successfully executed or not: in such a case, the results of a query are frequently decided by looking at the webpage that is being attacked itself – a blank page that is being returned probably has no results while if an attacker submits a malformed query, it should return the same page (that could perhaps look a little odd since some things might be missing, etc.) |
As you can see, there are not that many categories SQL injection falls under – however, while classic SQL injection is being used the most frequently, when classic SQL injection attacks do not work, attackers usually turn to the blind side of SQL – they try attacking applications with blind SQL injection.
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 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:
- 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.
- An attacker keeps crafting SQL queries – none of them return any error. However, he quickly finds that if he executes one type of a query, the data inside of your web application shows on the screen, after he executes another – the data dissapears. “Aha!”, – thinks the attacker. “Gotcha. Got a blind SQL injection flaw.”
As you might already notice, a blind SQL injection is such 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, he probes further, a query returns a blank page – hmmm... he changes the query and tries 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. You can find a live example of a web application firewall by visiting the website of one of the biggest & fastest data breach search engines in the world – BreachDirectory – but for now, let’s get back to the topic.
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 have 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:
| Type of Blind SQL Injection | Key Aspect |
|---|---|
| Time-based | Reliant on the response of the web application |
| Boolean-based Reliant on the response of the web application | |
| Time-based | Reliant on time |
| Boolean-based | Reliant on the "appearance" of the web application |
| Time-based | Usually slow because of the time required to confirm whether each query that was run executed correctly |
| Boolean-based | Usually slow because of the time spent evaluating the responses of the application in a visual manner |
| Time-based and Boolean-based | Usually prevented by employing basic security measures such as prepared statements, input validation, enforcing the principle of least privilege, etc. |
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!
Summary
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 differently 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, refine how errors are returned in your web applications, and, of course, keep an eye on the Arctype blog – you will find decent security-related advice over there as well.
Additionally, make sure to run a search through known data breach search engines such as BreachDirectory to ensure that your data is safe both during the day and the night, and until next time. See you in the next blog!
Top comments (0)