Blind SQL Injection

Revision as of 08:28, 12 February 2009 by KirstenS (talk | contribs) (References)

Jump to: navigation, search
This is an Attack. To view all attacks, please see the Attack Category page.

ASDR Table of Contents

Last revision (mm/dd/yy): 02/12/2009


When an attacker executes SQL Injection attacks, sometimes the server responds with error messages from the database server complaining that the SQL Query's syntax is incorrect. Blind SQL injection is identical to normal SQL Injection except that when an attacker attempts to exploit an application, rather then getting a useful error message, they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through SQL statements.

Threat Modeling

  • SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.
  • SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections.
  • The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.

Related Security Activities

How to Avoid SQL Injection Vulnerabilities

See the OWASP Development Guide article on how to Avoid SQL Injection Vulnerabilities.

How to Avoid SQL Injection Vulnerabilities

See the OWASP Code Review Guide article on how to Review Code for SQL Injection Vulnerabilities.

How to Test for SQL Injection Vulnerabilities

See the OWASP Testing Guide article on how to Test for SQL Injection Vulnerabilities.



Risk Factors



An attacker may verify whether a sent request returned True or False in a few ways:

(in)visible content

Having a simple page, which displays article with given ID as the parameter, the attacker may perform a couple of simple tests if a page is vulnerable to SQL Injection attack.

Example URL:

sends the following query to the database:

SELECT title, description, body FROM items WHERE ID = 2

The attacker may try to inject any (even invalid) query, what should cause the query to return no results: and 1=2

Now the SQL query should looks like this:

SELECT title, description, body FROM items WHERE ID = 2 and 1=2

Which means that the query is not going to return anything.

If the web application is vulnerable to SQL Injection, then it probably will not return anything. To make sure, the attacker will certainly inject a valid query: and 1=1

If the content of the page is the same, then the attacker is able to distinguish when the query is True or False.

What next? The only limitations are privileges set up by the database administrator, different SQL dialects and finally the attacker's imagination.

RDBMS fingerprinting

If the attacker is able to determine when his query returns True or False, then he may fingerprint the RDBMS. This will make the whole attack much easier to him. One of the most popular methods to do this is to call functions which will return the current date. MySQL, MS SQL or Oracle have different functions for that, respectively now(), getdate(), and sysdate().

Timing Attack

A Timing Attack depends upon injecting the following MySQL query:

SELECT IF(expression, true, false)

Using some time-taking operation e.g. BENCHMARK(), will delay server responses if the expression is True.

BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))
- will execute 5000000 times the ENCODE function.

Depending on the database server performence and its load, it should take just a moment to finish this operation. The important thing is, from the attacker's point of view, to specify high number of BENCHMARK() function repetitons, which should affect the server response time in a noticeable way.

Example combination of both queries:

1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null) FROM users WHERE user_id = 1;

If the server response was quite long we may expect that the first user password character with user_id = 1 is character '2'.

(CHAR(50) == '2')

Using this method for the rest of characters, it's possible to get to know entire password stored in the database. This method works even when the attacker injects the SQL queries and the content of the vulnerable page doesn't change.

Obviously, in this example the names of the tables and the number of columns was specified. However, it's possible to guess them or check with a trial and error method.

Other databases than MySQL also have implemented functions which allow them to use timing attacks:

  • MS SQL 'WAIT FOR DELAY '0:0:10
  • PostgreSQL - pg_sleep()

Conducting Blind_SQL_Injection attacks manually is very time consuming, but there are a lot of tools which automate this process. One of them is SQLMap ( developed within OWASP grant program. On the other hand, tools of this kind are very sensitive to even small deviations from the rule. This includes:

  • scanning othe WWW cluster, where clocks are not ideally synchronized,
  • WWW services where argument acquiring method was changed, e.g. from /index.php?ID=10 to /ID,10

Related Threat Agents

  • TBD

Related Attacks

Related Vulnerabilities

Related Controls


Online Resources