What is blind SQL Injection? Provide an example of blind sql injection as well.
In our SQL Injection Tutorial, we discussed how hackers use error messages from the database that they are trying to attack in order to determine whether or not that database is vulnerable to a SQL injection attack. But, what if database error messages are suppressed so that they are not displayed on the web page of a site that is under attack? Do hackers have some other way of running a SQL injection attack?
It turns out that hackers do actually have a way to run a SQL injection attack even when database error messages are disabled. This form of SQL injection is known as blind SQL injection.
Blind SQL injection versus SQL injection
What exactly is the difference between blind SQL injection and normal SQL injection? Well, in normal SQL injection hackers rely on error messages returned from the database in order to give them some clues on how to proceed with their SQL injection attack. But with blind SQL injection the hacker does not need to see any error messages in order to run his/her attack on the database – and that is exactly why it is called blind SQL injection. So, even if the database error messages are turned off a hacker can still run a blind SQL injection attack.
Here we present a tutorial on blind sql injection using an example of a hypothetical blind SQL injection attack below.
Example of Blind SQL Injection
For our example, let’s suppose that we have a fake example social networking site – let’s call it mybigspace.com – that has different profiles for people (just like Facebook). Each user on the site mybigspace.com has a unique ID number assigned to them that identifies their profile. And, a query string is used to retrieve each individual’s profile – so in the URL below, the user with an ID of 1008 will be pulled up and displayed on the page. Let’s say that the user ID of 1008 belongs to a user named “John Doe”. Here is what the URL that’s used to load John Doe’s profile would look like:
// this is John Doe's page: http://www.mybigspace.com?id=1008
Let’s assume that the user ID would be used to retrieve the user’s profile details (like links to pictures, his/her birthday, etc) from a database. So, if a user requests the URL “http://www.mybigspace.com?id=1008”, then that query string would be used to run some SQL on the servers of mybigspace.com. That SQL could look like this:
SELECT * FROM profiles WHERE ID = '1008';
We are assuming that there is a master table called profiles which stores all the different profiles of people who are on the social networking site.
But now let’s say that the hacker tries to inject some SQL into the URL query string – so the hacker tries to load this URL in his/her browser:
http://www.mybigspace.com?id=1008 AND 1=1
Blind SQL Injection uses simple boolean expressions
Loading the URL above might result in the server of mybigspace.com running the SQL below. Note that the SQL below contains a simple boolean expression – a “1 = 1” which will of course always return true because one is always equal to one. That expression is appended to the query string in the URL above. Here is the SQL we discussed:
SELECT * FROM profiles WHERE ID = '1008' AND 1=1;
We said that loading the URL “http://www.mybigspace.com?id=1008 AND 1=1” might result in mybigspace.com running the SQL above – the reason we said might is because of the fact that it depends on whether the server would allow the extra characters after the 1008 to be injected into the SQL. If the server does accept that SQL and allows it to be run, then the page that belongs to “John Doe” would be loaded just fine. And, the hacker will know that his SQL injection attack worked, which means that the site mybigspace.com is vulnerable to SQL injection attacks.
Of course, if the server does not respond with John Doe’s page when the URL “http://www.mybigspace.com?id=1008 AND 1=1” is requested, and instead just returns something like a “Page not found”, then the hacker knows that a blind SQL injection attack is probably not possible.
So, let’s continue with the assumption that the website is vulnerable to blind SQL injection. Now, the hacker can use more sophisticated queries to gather information about the server environment, and he can work his way into getting some potentially sensitive data. For instance, now if the hacker wants to find out which version of MySQL the server is running (assuming that it is running a MySQL database), then the hacker could try to load this URL, which has some extra SQL appended to check to see if the server is running MySQL version 5 :
http://www.mybigspace.com?id=1008 AND substring(@@version, 1, 1)=5
The SQL “substring(@@version, 1, 1)=5” just checks to see if the version of MySQL that is currently running is version 5 (through the “=5” check), and if it is running version 5 then the page will just load normally because the SQL will run without a problem (this is of course assuming that the website is vulnerable to SQL injection and is basically just running the SQL that is part of the query string). If mybigspace.com’s server is not running MySQL version 5 then the SQL “substring(@@version, 1, 1)=5” will return false because the check for equality is false. This means that the page will probably not load because the profile will not be retrieved, and so the hacker knows that the version of MySQL being run is not version 5.
Blind SQL Injection Prevention
As we have made pretty clear so far, a blind SQL injection attack can be done even if the display of database error messages is turned off. So, clearly turning off error message is not enough for prevention purposes. Prepared statements are great for preventing blind SQL injection because the SQL is compiled before any user input is added, which makes it impossible for user input to change and therefore compromise the integrity of the SQL statement.
You can also use a vulnerability assessment tool to test your application and see how it responds to blind SQL injection attacks. There are many tools like that out there which will do this for you for a small fee, and are great at helping you prevent blind SQL injection attacks.
Blind SQL Injection is slower than normal attacks
The hacker can continue on this way, and slowly find out more and more information about the database system under attack. You can also see that blind SQL injection is quite a bit slower than normal SQL injection attacks because of the fact that the hacker has to deal with a database system that does not display error messages.