This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Blind SQL Injection"

From OWASP
Jump to: navigation, search
((in)visible content)
 
(45 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Security Focus Area]]
 +
__NOTOC__
 +
<br>
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
==Overview==
+
==Description==
 +
Blind SQL (Structured Query Language) injection is a type of [[SQL Injection]] attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.
  
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.
+
When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query's syntax is incorrect. Blind SQL injection is nearly identical to normal [[SQL Injection]], the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible. .
  
 
==Threat Modeling==
 
==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.
+
Same as for [[SQL Injection]]
* 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==
+
==Risk Factors==
 
+
Same as for [[SQL Injection]]
===How to Avoid SQL Injection Vulnerabilities===
 
 
 
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 
 
 
===How to Avoid SQL Injection Vulnerabilities===
 
 
 
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.
 
 
 
===How to Test for SQL Injection Vulnerabilities===
 
 
 
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection|Test for SQL Injection]] Vulnerabilities.
 
 
 
[[Category:Security Focus Area]]
 
__NOTOC__
 
  
 
==Examples ==
 
==Examples ==
 +
An attacker may verify whether a sent request returned true or false in a few ways:
  
Verification whether sent request returned True or False the attacker may conduct in a few ways:
+
===Content-based===
 
+
Using a simple page, which displays an article with given ID as the parameter, the attacker may perform a couple of simple tests to determine if the page is vulnerable to SQL Injection attacks.
 
 
===(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:
 
Example URL:
Line 47: Line 32:
 
SELECT title, description, body FROM items WHERE ID = 2
 
SELECT title, description, body FROM items WHERE ID = 2
 
</prE>
 
</prE>
The attacker may try to inject any (even invalid) query, what should cause to return no results by the query:
+
The attacker may then try to inject a query that returns 'false':
 
<pre>
 
<pre>
 
http://newspaper.com/items.php?id=2 and 1=2
 
http://newspaper.com/items.php?id=2 and 1=2
 
</pre>
 
</pre>
Now the SQL query should looks like that:
+
Now the SQL query should looks like this:
 
<pre>
 
<pre>
 
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
 
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
 
</pre>
 
</pre>
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 inject a query that will return 'true':
 
 
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:
 
 
<pre>
 
<pre>
 
http://newspaper.com/items.php?id=2 and 1=1
 
http://newspaper.com/items.php?id=2 and 1=1
 
</pre>
 
</pre>
If the content of the page is the same, then the attacker is able to distinguish when the query is True or False.
+
If the content of the page that returns 'true' is different than that of the page that returns 'false', then the attacker is able to distinguish when the executed query returns true or false.
  
 +
Once this has been verified, the only limitations are privileges set up by the database administrator, different SQL syntax, and the attacker's imagination.
  
What next? The only limitations are privileges set up by the database administrator, different SQL dialects and finally the attacker's imagination.
 
  
===RDBMS fingerprinting===
+
===Time-based===
  
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
+
This type of blind SQL injection relies on the database pausing for a specified amount of time, then returning the results, indicating successful SQL query executing. Using this method, an attacker enumerates each letter of the desired piece of data using the following logic:
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()''.
 
  
 +
If the first letter of the first database's name is an 'A', wait for 10 seconds.
  
===Timing Attack===
+
If the first letter of the first database's name is an 'B', wait for 10 seconds. etc.
  
a Timing Attack depends upon injecting the following MySQL query:
+
'''Microsoft SQL Server'''
 +
<pre>
 +
http://www.site.com/vulnerable.php?id=1' waitfor delay '00:00:10'--
 +
</pre>
 +
 
 +
'''MySQL'''
 
<pre>
 
<pre>
 
SELECT IF(expression, true, false)
 
SELECT IF(expression, true, false)
 
</pre>
 
</pre>
Using some time taking operation e.g. BENCHMARK(), will delay server
+
Using some time-taking operation e.g. BENCHMARK(), will delay server
responses if the expression will be True.
+
responses if the expression is True.
  
<pre>BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))</pre> - will execute 5000000 times the ENCODE function.
+
<pre>BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))</pre> - will execute the ENCODE function 5000000 times.
  
Depending on the database server performence and its load, it should
+
Depending on the database server's performance and load, it should
 
take just a moment to finish this operation. The important thing is,
 
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()
+
from the attacker's point of view, to specify a high-enough number of BENCHMARK()
function repetitons, which should affect in a noticeable way the server
+
function repetitions to affect the database
response time.
+
response time in a noticeable way.
  
Examplary combination of both queries:
+
Example combination of both queries:
 
<pre>
 
<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;
 
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>
 
</pre>
If the server response was quite long we may expect, that the first user password character with user_id = 1 is character '2'.
+
If the database response took a long time, we may expect that the first user password character with user_id = 1 is character '2'.
 
<pre>
 
<pre>
 
(CHAR(50) == '2')
 
(CHAR(50) == '2')
 
</pre>
 
</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.
+
Using this method for the rest of characters, it's possible to enumerate entire passwords 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 trial and error method.
+
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.
  
Different databases than MySQL also have implemented functions, which allow to use timing attacks:
+
Databases other than MySQL also have time-based functions which allow them to be used for time-based attacks:
 
* MS SQL 'WAIT FOR DELAY '0:0:10''
 
* MS SQL 'WAIT FOR DELAY '0:0:10''
 
* PostgreSQL - pg_sleep()
 
* PostgreSQL - pg_sleep()
  
Conducting Blind_SQL_Injection attacks manually is very time consuming. There are a lot of tools which automate this process. One of them is SQLMap (http://sqlmap.sourceforge.net/) 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:
+
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 (http://sqlmap.org/) partly 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,
+
 
 +
* scanning other website clusters, where clocks are not ideally synchronized,
 
* WWW services where argument acquiring method was changed, e.g.  from /index.php?ID=10 to /ID,10
 
* WWW services where argument acquiring method was changed, e.g.  from /index.php?ID=10 to /ID,10
  
==Related [[Threat Agents]]==
+
===Remote Database Fingerprinting===
  
* [[:Category:Command Execution]]
+
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. If the time-based approach is used, this helps determine what type of database is in use. Another popular methods to do this is to call functions which will return the current date. MySQL, MSSQL, and Oracle have different functions for that, respectively ''now()'', ''getdate()'', and ''sysdate()''.
  
 +
==Related [[Threat Agents]]==
 +
Same as for [[SQL Injection]]
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
 
 
* [[Blind_XPath_Injection]]
 
* [[Blind_XPath_Injection]]
 
* [[SQL_Injection]]
 
* [[SQL_Injection]]
Line 122: Line 111:
 
* [[LDAP_injection]]
 
* [[LDAP_injection]]
 
* [[Server-Side_Includes_%28SSI%29_Injection]]
 
* [[Server-Side_Includes_%28SSI%29_Injection]]
 
  
 
==Related [[Vulnerabilities]]==
 
==Related [[Vulnerabilities]]==
 
 
* [[Injection_problem]]
 
* [[Injection_problem]]
  
 +
==Related [[Controls]]==
 +
* [[:Category:Input Validation]]
  
==Related [[Controls]]==
+
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 +
<br>See the OWASP [[SQL Injection Prevention Cheat Sheet]].
  
* [[:Category:Input Validation]]
+
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.
  
 +
See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection    (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.
  
 
==References==
 
==References==
 
 
* http://www.cgisecurity.com/questions/blindsql.shtml
 
* http://www.cgisecurity.com/questions/blindsql.shtml
 
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
 
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
Line 143: Line 133:
  
 
'''Online Resources'''
 
'''Online Resources'''
* [http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf more Advanced SQL Injection] - by NGS
+
* [http://www.nccgroup.com/Libraries/Document_Downloads/more__Advanced_SQL_Injection.sflb.ashx more Advanced SQL Injection] - by NGS
 
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
 
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
 
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
 
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
 
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
 
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
* [http://www.securitydocs.com/library/2651 Blind SQL Injection]
+
* Kevin Spett from SPI Dynamics: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf
* http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf
+
* http://www.imperva.com/resources/whitepapers.asp?t=ADC
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
+
* [https://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt Advanced SQL Injection]
* [http://wcsc.myweb.usf.edu/tutorials/SQL_Injection.ppt SQL Injection Attacks]
 
  
 
'''Tools'''
 
'''Tools'''
 
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
 
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [http://www.0x90.org/releases/absinthe/ [Absinthe :: Automated Blind SQL Injection] // ver1.3.1
+
* [http://www.0x90.org/releases/absinthe/ Absinthe :: Automated Blind SQL Injection] // ver1.3.1
 
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
 
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
* [http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project SQLiX - SQL Injection Scanner] in Perl
+
* [[:Category:OWASP_SQLiX_Project|SQLiX - SQL Injection Scanner]] in Perl
* [http://sqlmap.sourceforge.net sqlmap, a blind SQL injection tool] in Python
+
* [http://sqlmap.org/ sqlmap, automatic SQL injection tool] in Python
* [http://www.514.es/2006/12/inyeccion_de_codigo_bsqlbf12th.html bsqlbf, a blind SQL injection tool] in Perl
+
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl
  
  
 
[[Category:Injection]]
 
[[Category:Injection]]
 +
[[Category: Attack]]

Latest revision as of 10:22, 26 August 2013

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


Last revision (mm/dd/yy): 08/26/2013

Description

Blind SQL (Structured Query Language) injection is a type of SQL Injection attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.

When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query's syntax is incorrect. Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible. .

Threat Modeling

Same as for SQL Injection

Risk Factors

Same as for SQL Injection

Examples

An attacker may verify whether a sent request returned true or false in a few ways:

Content-based

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

Example 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 then try to inject a query that returns 'false':

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

Now the SQL query should looks like this:

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

If the web application is vulnerable to SQL Injection, then it probably will not return anything. To make sure, the attacker will inject a query that will return 'true':

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

If the content of the page that returns 'true' is different than that of the page that returns 'false', then the attacker is able to distinguish when the executed query returns true or false.

Once this has been verified, the only limitations are privileges set up by the database administrator, different SQL syntax, and the attacker's imagination.


Time-based

This type of blind SQL injection relies on the database pausing for a specified amount of time, then returning the results, indicating successful SQL query executing. Using this method, an attacker enumerates each letter of the desired piece of data using the following logic:

If the first letter of the first database's name is an 'A', wait for 10 seconds.

If the first letter of the first database's name is an 'B', wait for 10 seconds. etc.

Microsoft SQL Server

http://www.site.com/vulnerable.php?id=1' waitfor delay '00:00:10'--

MySQL

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 the ENCODE function 5000000 times.

Depending on the database server's performance and load, it should take just a moment to finish this operation. The important thing is, from the attacker's point of view, to specify a high-enough number of BENCHMARK() function repetitions to affect the database 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 database response took a long time, 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 enumerate entire passwords 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.

Databases other than MySQL also have time-based functions which allow them to be used for time-based 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 (http://sqlmap.org/) partly 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 other website clusters, where clocks are not ideally synchronized,
  • WWW services where argument acquiring method was changed, e.g. from /index.php?ID=10 to /ID,10

Remote Database 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. If the time-based approach is used, this helps determine what type of database is in use. Another popular methods to do this is to call functions which will return the current date. MySQL, MSSQL, and Oracle have different functions for that, respectively now(), getdate(), and sysdate().

Related Threat Agents

Same as for SQL Injection

Related Attacks

Related Vulnerabilities

Related Controls

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

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

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

References

Online Resources

Tools