OWASP - User contributions [en]

User:Shivang Desai

2015-01-31T06:03:43Z

Shivang Desai:

Certified Security Professional and Researcher, India.
Security is my passion and open source is my love.

Mobile Top 10 2014-M8

2015-01-30T23:40:06Z

Shivang Desai:

<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
{{Top_10_2010:SubsectionColoredTemplate|<center>Security Decisions Via Untrusted Inputs</center>||year=2014}}
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities but not limited, include users, malwares or a vulnerable app</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Exploitability of this vulnerability remains easy. An attacker with access to app can intercept intermediate calls and manipulate results via parameter tampering. </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Developers generally use hidden fields and values or any hidden functionality to distinguish higher level users from lower level users. An attacker can intercept the calls (IPC or web service calls) and temper with such sensitive parameters. Weak implementation of such functionalities leads to improper behavior of an app and even granting higher level permissions to an attacker.This can easily be exploited through hooking functionality. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability may lead to privilege escalation providing access of higher authorities and functionalities to an attacker. It can even bypass security mechanisms implemented by the app leading to loss of confidentiality and integrity. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability leads to loss of reputation. At the same time, impacting and harming the integrity and confidentiality. </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:

* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}
iOS Specific Examples:
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.

Android Specific Examples
*

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}
References

[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]

Mobile Top 10 2014-M8

2015-01-30T23:30:54Z

Shivang Desai:

<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
{{Top_10_2010:SubsectionColoredTemplate|<center>Security Decisions Via Untrusted Inputs</center>||year=2014}}
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities but not limited, include users, malwares or a vulnerable app</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Developers generally use hidden fields and values or any hidden functionality to distinguish higher level users from lower level users. An attacker can intercept the calls (IPC or web service calls) and temper with such sensitive parameters. Weak implementation of such functionalities leads to improper behavior of an app and even granting higher level permissions to an attacker.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability may lead to privilege escalation providing access of higher authorities and functionalities to an attacker. It can even bypass security mechanisms implemented by the app leading to loss of confidentiality and integrity. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability leads to loss of reputation. At the same time, impacting and harming the integrity and confidentiality. </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:

* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}
iOS Specific Examples:
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.

Android Specific Examples
*

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}
References

[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]

Mobile Top 10 2014-M8

2015-01-30T23:23:03Z

Shivang Desai:

<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
{{Top_10_2010:SubsectionColoredTemplate|<center>Security Decisions Via Untrusted Inputs</center>||year=2014}}
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities but not limited, include users, malwares or a vulnerable app</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector Description </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability may lead to privilege escalation providing access of higher authorities and functionalities to an attacker. It can even bypass security mechanisms implemented by the app leading to loss of confidentiality and integrity. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability leads to loss of reputation. At the same time, impacting and harming the integrity and confidentiality. </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:

* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}
iOS Specific Examples:
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.

Android Specific Examples
*

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}
References

[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]

Mobile Top 10 2014-M8

2015-01-30T23:22:43Z

Shivang Desai:

<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
{{Top_10_2010:SubsectionColoredTemplate|<center>Security Decisions Via Untrusted Inputs</center>||year=2014}}
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities but not limited, include users, malwares or a vulnerable app</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector Description </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability may lead to privilege escalation providing access of higher authorities and functionalities to an attacker. It can even bypass security mechanisms implemented by the app leading to loss of confidentiality and integrity. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability leads to loss of reputation. At the same time, impacting and harming the integrity and confidentiality. </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:

* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}
iOS Specific Examples:
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.

Android Specific Examples
*

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}
References

[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]

Mobile Top 10 2014-M8

2015-01-30T23:19:36Z

Shivang Desai: Adding description for Technical Impacts.

<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
{{Top_10_2010:SubsectionColoredTemplate|<center>Security Decisions Via Untrusted Inputs</center>||year=2014}}
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities but not limited, include users, malwares or a vulnerable app</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector Description </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability may lead to privilege escalation providing access of higher authorities and functionalities to an attacker. It can even bypass security mechanisms implemented by the app leading to loss of confidentiality and integrity. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:

* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}
iOS Specific Examples:
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.

Android Specific Examples
*

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}
References

[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]

Mobile Top 10 2014-M8

2015-01-30T23:09:37Z

Shivang Desai: Adding description for Threat Agents.

<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
{{Top_10_2010:SubsectionColoredTemplate|<center>Security Decisions Via Untrusted Inputs</center>||year=2014}}
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities but not limited, include users, malwares or a vulnerable app</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector Description </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Technical Impacts</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:

* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}
iOS Specific Examples:
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.

Android Specific Examples
*

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}
References

[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]

Blind SQL Injection

2013-08-26T10:22:19Z

Shivang Desai:

{{Template:Attack}}
[[Category:OWASP ASDR Project]]
[[Category:Security Focus Area]]
__NOTOC__
 

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==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:
<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 then try to inject a query that returns 'false':
<pre>
http://newspaper.com/items.php?id=2 and 1=2
</pre>
Now the SQL query should looks like this:
<pre>
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
</pre>
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':
<pre>
http://newspaper.com/items.php?id=2 and 1=1
</pre>
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'''
<pre>
http://www.site.com/vulnerable.php?id=1' waitfor delay '00:00:10'--
</pre>

'''MySQL'''
<pre>
SELECT IF(expression, true, false)
</pre>
Using some time-taking operation e.g. BENCHMARK(), will delay server
responses if the expression is True.

<pre>BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))</pre> - 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:
<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 database response took a long time, 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 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]]==
* [[Blind_XPath_Injection]]
* [[SQL_Injection]]
* [[XPATH_Injection]]
* [[LDAP_injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Related [[Vulnerabilities]]==
* [[Injection_problem]]

==Related [[Controls]]==
* [[:Category:Input Validation]]

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 See the OWASP [[SQL Injection Prevention Cheat Sheet]].

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==
* 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'''
* [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://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?]
* Kevin Spett from SPI Dynamics: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf
* http://www.imperva.com/resources/whitepapers.asp?t=ADC
* [https://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt Advanced SQL Injection]

'''Tools'''
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [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
* [[:Category:OWASP_SQLiX_Project|SQLiX - SQL Injection Scanner]] in Perl
* [http://sqlmap.org/ sqlmap, automatic SQL injection tool] in Python
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl

[[Category:Injection]]
[[Category: Attack]]

Blind SQL Injection

2013-08-26T10:21:26Z

Shivang Desai: