Difference between revisions of "Blind SQL Injection"

From OWASP
Jump to: navigation, search
(Description)
m (Categories)
(One intermediate revision by one user not shown)
Line 2: Line 2:
  
 
==Description==
 
==Description==
Blind SQL injection is identical to normal [[SQL injection]], however, when such an attack is performed a handled error message is returned. This results in no generic database error messages and without disclosing such information the attacker is working '<i>blindly</i>.'
 
  
 +
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.
 +
 +
==Examples ==
 +
 +
Verification whether sended request returned True or False the attacker may conduct in a few ways:
 +
 +
 +
Example ('''(in)visible content''')
 +
 +
Having a simple page, which displays article with given ID as the parameter, the attacker may perform a couple simple tests if a page
 +
is vulnerable to sql injection attack.
 +
 +
Examplary URL:
 +
<pre>
 +
http://newspaper.com/items.php?id=2
 +
</pre>
 +
sends the following query to the database:
 +
<pre>
 +
SELECT title, description, body FROM items WHERE ID = 2
 +
</prE>
 +
The attacker may try to inject any (even invalid) query, what should cause to return no results by the query:
 +
<pre>
 +
http://newspaper.com/items.php?id=2 and 1=2
 +
</pre>
 +
Now the sql query should looks like that:
 +
<pre>
 +
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
 +
</pre>
 +
What means that query is not going to return anything.
 +
 +
If the web application is vulnerable to sql injection, then probably will not return anything. To make sure the attacker will certainly inject a valid query:
 +
<pre>
 +
http://newspaper.com/items.php?id=2 and 1=1
 +
</pre>
 +
If the content of the page will be the same, then the attacker is able to distinguish when the query is True of False.
 +
 +
 +
What next? The only limitations are privileges set up by the database administrator, different SQL dialects and finally the attacker imagination.
 +
 +
 +
Example ('''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 method to do it, 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()''.
 +
 +
 +
Example ('''timing attack''')
 +
 +
Timing  attack depends upon injecting the following MySQL query:
 +
<pre>
 +
SELECT IF(expression, true, false)
 +
</pre>
 +
Using some time taking operation e.g. BENCHMARK(), will delay server
 +
responses if the expression will be True.
 +
 +
<pre>BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))</pre> - 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 immportant thing is,
 +
from the attacker's point of view, to specify high number of BENCHMARK()
 +
function repetitons, which should affect in a noticeable way the server
 +
response time.
 +
 +
Examplary combination of both queries:
 +
<pre>
 +
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;
 +
</pre>
 +
If the server response was quite long we may expect, that the first user password character with user_id = 1 is character '2'.
 +
<pre>
 +
(CHAR(50) == '2')
 +
</pre>
 +
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 is 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 trial and error method.
 +
 +
Different databases than MySQL also have implemented functions, which allow to use timing attacks:
 +
* MS SQL 'WAIT FOR DELAY '0:0:10''
 +
* PostgreSQL - pg_sleep()
 +
 +
Conducting Blind_SQL_Injection attacks manually are very time taking. There are a lot of tools, which automates this process. One of them is SQLMap (http://sqlmap.sourceforge.net/) developed within OWASP grant program. In the other hand the practice shows that 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
 +
 +
 +
References:
 +
* http://www.cgisecurity.com/questions/blindsql.shtml
 +
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
 +
* http://www.securitydocs.com/library/2651
 +
* http://seclists.org/bugtraq/2005/Feb/0288.html
 +
* http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/
  
 
'''Online Resources'''
 
'''Online Resources'''
Line 23: Line 113:
 
* [http://www.514.es/2006/12/inyeccion_de_codigo_bsqlbf12th.html bsqlbf, a blind SQL injection tool] in Perl
 
* [http://www.514.es/2006/12/inyeccion_de_codigo_bsqlbf12th.html bsqlbf, a blind SQL injection tool] in Perl
  
==Examples ==
 
  
 
==Related Threats==
 
==Related Threats==
 +
 +
* [[:Category:Command_Execution]]
  
 
==Related Attacks==
 
==Related Attacks==
  
==Related Problems==
+
* [[Blind_XPath_Injection]]
* [[Injection problem]]
+
* [[SQL_Injection]]
 +
* [[XPATH_Injection]]
 +
* [[LDAP_injection]]
 +
* [[Server-Side_Includes_%28SSI%29_Injection]]
 +
 
 +
==Related Vulnerabilities==
 +
 
 +
* [[Injection_problem]]
  
 
==Related Countermeasures==
 
==Related Countermeasures==
 +
 +
* [[:Category:Input Validation]]
  
 
==Categories==
 
==Categories==
 +
 +
[[Category:Injection]]
 +
 
[[Category:Attack]]
 
[[Category:Attack]]
 
[[Category:Injection Attack]]
 
[[Category:Injection Attack]]

Revision as of 17:50, 4 November 2007

This is an Attack. To view all attacks, please see the Attack Category page.


Description

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.

Examples

Verification whether sended request returned True or False the attacker may conduct in a few ways:


Example ((in)visible content)

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

Examplary URL:

http://newspaper.com/items.php?id=2

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 to return no results by the query:

http://newspaper.com/items.php?id=2 and 1=2

Now the sql query should looks like that:

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

What means that query is not going to return anything.

If the web application is vulnerable to sql injection, then probably will not return anything. To make sure the attacker will certainly inject a valid query:

http://newspaper.com/items.php?id=2 and 1=1

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


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


Example (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 method to do it, 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().


Example (timing attack)

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 will be 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 immportant thing is, from the attacker's point of view, to specify high number of BENCHMARK() function repetitons, which should affect in a noticeable way the server response time.

Examplary 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 is 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 trial and error method.

Different databases than MySQL also have implemented functions, which allow to use timing attacks:

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

Conducting Blind_SQL_Injection attacks manually are very time taking. There are a lot of tools, which automates this process. One of them is SQLMap (http://sqlmap.sourceforge.net/) developed within OWASP grant program. In the other hand the practice shows that 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


References:

Online Resources

Tools


Related Threats

Related Attacks

Related Vulnerabilities

Related Countermeasures

Categories