SQL Injection, originally discovered in 1998, is one of the oldest bugs that are still being actively exploited today. The latest OWASP Top 10 still lists Injection as the most important vulnerability.
Back in the days, the most basic way to check for SQL Injection was to use an inverted comma
' in the field or parameter that the attacker is trying to check. This will cause an error in the SQL statement, which will is shown by the web application and which would clearly indicate that the field is vulnerable to SQL Injection. The error would look similar to:
Microsoft SQL Native Client error '80040e14' Unclosed quotation mark after the character string ''. /target.asp, line 9
The attacker can then try different types of requests to cause the database to return information about itself in the error responses. The attacker can use this information to fingerprint the database, build the database schema, retrieve data from any table in the database and proceed to escalating his attack.
Web server administrators quickly realised that showing errors to the general public is not a wise thing to do, so they started suppressing detailed error messages. This is obviously a flawed solution, since it does not address the underlying problem – user input can still be parsed by the SQL Interpreter as part of an SQL statement.
This is the time when Blind SQL Injection was born. Hackers needed to know when the input is being interpreted as an SQL statement. There are 2 techniques that are commonly used to do this – Content-based Blind SQL Injection and Time-based Blind SQL Injection.
Content-based Blind SQL Injection
For this type of attack, the hacker will try to verify if the database is susceptible to Blind SQL Injection by comparing the results of different queries which return
Take for example a shop’s web portal, which displays items that are for sale. The following link will display details about item 34, which are retrieved from a database.
The SQL statement used for this request is:
SELECT name, description, price FROM Store_table WHERE id = 34
The attacker may manipulate the request to:
http://www.shop.local/item.php?id=34 and 1=2
The SQL Statement changes to:
SELECT name, description, price FROM Store_table WHERE ID = 34 and 1=2
This will cause the query to return
FALSE, and no items are displayed in the list. The attacker then proceeds to change the request to:
http://www.shop.local/item.php?id=34 and 1=1
And the SQL Statement changes to:
SELECT name, description, price FROM Store_table WHERE ID = 34 and 1=1
TRUE, and the details of item with
ID 34 are shown. This is a clear indication that the page is vulnerable.
Time-based Blind SQL Injection
For Time-based attacks, the attacker needs to instruct the database to perform a time-intensive operation. If the web site does not return a response immediately, the web application is vulnerable to Blind SQL Injection. A popular time intensive operation is the
Taking the previous example, the attacker would measure how long it takes for the web server to respond to a normal query. The attacker would then issue the following request:
http://www.shop.local/item.php?id=34 and if(1=1, sleep(10), false)
The web application is vulnerable if the response is delayed by 10 seconds.
Blind SQL Injection is often used to build the database schema, and get all the data in the database. This is done using brute force techniques and does require many requests to be sent to the server.
Acunetix can detect Blind SQL Injection vulnerabilities. Acunetix also includes a Blind SQL Injector tool , which allows the pen tester to verify that the Blind SQL vulnerability exists and demonstrate the consequences of the vulnerability.