OWASP - User contributions [en]

User:Marius Quadflieg

2008-08-04T12:56:21Z

Marius Quadflieg:

IT Compliance Management - MGI METRO Group Information Technology GmbH

Software Engineering Student - Fontys Hogeschool Venlo (NL)

'''Blog:''' [http://www.portal4gamers.de www.portal4gamers.de]

'''Email:''' marius at quadflieg dot name

'''PGP Key:''' [http://pgp.mit.edu:11371/pks/lookup?search=0xD8168DB7&op=index 0xD8168DB7]

Top 10 2007-Information Leakage and Improper Error Handling

2008-03-10T09:37:43Z

Marius Quadflieg: /* Protection */

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Applications can also leak internal state via how long they take to process certain operations or via different responses to differing inputs, such as displaying the same error text with different error numbers. Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks.

== Environments Affected ==

All web application frameworks are vulnerable to information leakage and improper error handling.

== Vulnerability ==

Applications frequently generate error messages and display them to users. Many times these error messages are quite useful to attackers, as they reveal implementation details or information that is useful in exploiting a vulnerability. There are several common examples of this:

*Detailed error handling, where inducing an error displays too much information, such as stack traces, failed SQL statements, or other debugging information
*Functions that produce different results based upon different inputs. For example, supplying the same username but different passwords to a login function should produce the same text for no such user, and bad password. However, many systems produce different error codes

== Verifying Security ==

The goal is to verify that the application does not leak information via error messages or other means.

Automated approaches: Vulnerability scanning tools will usually cause error messages to be generated. Static analysis tools can search for the use of APIs that leak information, but will not be able to verify the meaning of those messages.

Manual approaches: A code review can search for improper error handling and other patterns that leak information, but it is time-consuming. Testing will also generate error messages, but knowing what error paths were covered is a challenge.

== Protection ==

Developers should use tools like OWASP's WebScarab to try to make their application generate errors. Applications that have not been tested in this way will almost certainly generate unexpected error output. Applications should also include a standard exception handling architecture to prevent unwanted information from leaking to attackers.

Preventing information leakage requires discipline. The following practices have proven effective:

*'''Ensure that the entire software development team shares a''' '''common approach to exception handling'''.
*'''Disable or limit detailed error handling'''. In particular, do not display debug information to end users, stack traces, or path information.
*'''Ensure that secure paths that have multiple outcomes return similar or identical error messages''' in roughly the same time. If this is not possible, consider imposing a random wait time for all transactions to hide this detail from the attacker.
*Various layers may return fatal or exceptional results, such as the database layer, the underlying web server (IIS, Apache, etc). It is vital that '''errors from all these layers are adequately checked and configured to prevent error messages from being exploited by intruders'''.
*Be aware that common frameworks return different HTTP error codes depending on if the error is within your custom code or within the framework’s code. '''It is worthwhile creating a default error handler which returns an appropriately sanitized error message for most users in production for all error paths'''.
*Overriding - Although security through obscurity, choosing to override the default error handler so that it always returns “200” (OK) error screens reduces the ability of automated scanning tools from determining if a serious error occurred. While this is “security through obscurity,” it can provide an extra layer of defense.
*Some larger organizations have chosen to include random / unique error codes amongst all their applications. This can assist the help desk with finding the correct solution for a particular error, but it may also allow attackers to determine exactly which path an application failed.

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580]

== Related Articles ==
* [[Error Handling]]
* [[:Category:Sensitive Data Protection Vulnerability]]
== References ==

*CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215 (Information Leak Through Debug Information), CWE-209 (Error Message Information Leak), others.
*WASC Threat Classification:
**[http://www.webappsec.org/projects/threat/classes/information_leakage.shtml http://www.webappsec.org/projects/threat/classes/information_leakage.shtml]
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}

Top 10 2007-Malicious File Execution

2008-02-26T11:57:15Z

Marius Quadflieg: /* Protection */ Changed gramatical structure and added a space between two words

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Insecure Direct Object Reference|useprev=PrevLink|prev=-Injection Flaws|usemain=MainLink|main=}}

Malicious file execution vulnerabilities are found in many applications. Developers will often directly use or concatenate potentially hostile input with file or stream functions, or improperly trust input files. On many platforms, frameworks allow the use of external object references, such as URLs or file system references. When the data is insufficiently checked, this can lead to arbitrary remote and hostile content being included, processed or invoked by the web server.

This allows attackers to perform:

*Remote code execution
*Remote root kit installation and complete system compromise
*On Windows, internal system compromise may be possible through the use of PHP’s SMB file wrappers
This attack is particularly prevalent on PHP, and extreme care must be taken with any stream or file function to ensure that user supplied input does not influence file names.

== Environments Affected ==

All web application frameworks are vulnerable to malicious file execution if they accept filenames or files from the user. Typical examples include: .NET assemblies which allow URL file name arguments, or code which accepts the user’s choice of filename to include local files.

'''PHP is particularly vulnerable''' to remote file include (RFI) attack through parameter tampering with any file or streams based API.

== Vulnerability ==

A common vulnerable construct is:

<code>include $_REQUEST['filename’];</code>

Not only does this allow evaluation of remote hostile scripts, it can be used to access local file servers (if PHP is hosted upon Windows) due to SMB support in PHP’s file system wrappers.

Other methods of attack include:

*Hostile data being uploaded to session files, log data, and via image uploads (typical of forum software)
*Using compression or audio streams, such as zlib:// or ogg:// which do not inspect the internal PHP URL flag and thus allow access to remote resources even if allow_url_fopen or allow_url_include is disabled
*Using PHP wrappers, such as php://input and others to take input from the request POST data rather than a file
*Using PHP’s data: wrapper, such as <code>data:;base64,PD9waHAgcGhwaW5mbygpOz8+</code>
As this list is extensive (and periodically changes), it is vital to use a properly designed security architecture and robust design when dealing with user supplied inputs influencing the choice of server side filenames and access.

Although PHP examples have been given, this attack is also applicable in different ways to .NET and J2EE. Applications written in those frameworks need to pay particular attention to code access security mechanisms to ensure that filenames supplied by or influenced by the user do not allow security controls to be obviated.

For example, it is possible that XML documents submitted by an attacker will have a hostile DTD that forces the XML parser to load a remote DTD, and parse and process the results. An Australian security firm has demonstrated this approach to port scanning behind firewalls. See [SIF01] in this chapter’s references for more information.

The damage this particular vulnerability causes is directly related to the strength of the sandbox / platform isolation controls in the framework. As PHP is rarely isolated and has no sandbox concept or security architecture, the damage is far worse for an attack than other platforms with limited or partial trust, or are contained within a suitable sand box, such as when a web app is running under a JVM with the security manager properly enabled and configured (which is rarely the default).

== Verifying Security ==

Automated approaches: Vulnerability scanning tools will have difficulty identifying the parameters that are used in a file include or the syntax for making them work. Static analysis tools can search for the use of dangerous APIs, but cannot verify that appropriate validation or encoding might be in place to protect against the vulnerability.

Manual approaches: A code review can search for code that might allow a file to be included in the application, but there are many possible mistakes to recognize. Testing can also detect these vulnerabilities, but identifying the particular parameters and the right syntax can be difficult.

== Protection ==

Preventing remote file include flaws takes some careful planning at the architectural and design phases, through to thorough testing. In general, a well-written application will not use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions), and will have firewall rules in place preventing new outbound connections to the Internet or internally back to any other server. However, many legacy applications will continue to have a need to accept user supplied input.

Among the most important considerations are:

*'''Use an indirect object reference map''' (see section A4 for more details). For example, where a partial filename was once used, consider a hash of the partial reference. Instead of :

<code><select name=”language”>
<option value=”English”>English</option></code>

use

<code><select name=”language”>
<option value=”78463a384a5aa4fad5fa73e2f506ecfc”>English</option></code>

Consider using salts to prevent brute forcing of the indirect object reference. Alternatively, just use index values such as 1, 2, 3, and ensure that the array bounds are checked to detect parameter tampering.3.

*'''Use explicit taint checking mechanisms''', if your language supports it. Otherwise, consider a variable naming scheme to assist with taint checking:
<code>$hostile = &$_POST; // refer to POST variables, not $_REQUEST</code>
<code>$safe[‘filename’]= validate_file_name($hostile[‘unsafe_filename’]); // make it safe</code>

Therefore any operation based upon hostile input is immediately obvious:
<code>WRONG: require_once($_POST[‘unsafe_filename’] . ‘inc.php’);</code>
<code>RIGHT: require_once($safe[‘filename’] . ‘inc.php’);</code>

*'''Strongly validate user''' input using "accept known good" as a strategy
*'''Add firewall''' rules to prevent web servers making new connections to external web sites and internal systems. For high value systems, isolate the web server in its own VLAN or private subnet
*'''Check any user supplied files or filenames''' taken from the user for legitimate purposes, which cannot obviate other controls. Otherwise be obviated, tainting could include user supplied data in the session object, avatars and images, PDF reports, temporary files, and so on
*'''Consider implementing a chroot jail '''or other sand box mechanisms such as virtualization to isolate applications from each other
*'''PHP:''' '''Disable allow_url_fopen and allow_url_include''' in php.ini and consider building PHP locally to not include this functionality. Very few applications need this functionality and thus these settings should be enabled on a per application basis
*'''PHP: Disable register_globals and use E_STRICT to find uninitialized variables'''
*'''PHP: Ensure that all file and streams functions (stream_*)''' '''are carefully vetted'''. Ensure that the user input is not supplied any function which takes a filename argument, including:
<code>include() include_once() require() require_once() fopen() imagecreatefromXXX() file() file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file()</code>

*PHP: Be extremely cautious if data is passed to system() eval() passthru() or ` (the backtick operator).
*With J2EE, ensure that the security manager is enabled and properly configured and that the application is demanding permissions appropriately
*With ASP.NET, please refer to the documentation on partial trust, and design your applications to be segmented in trust, so that most of the application exists in the lowest possible trust state possible

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722]

== References ==

*CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95 (Eval injection), CWE-434 (Unrestricted file upload)
*WASC Threat Classification:
[http://www.webappsec.org/projects/threat/classes/os_commanding.shtml http://www.webappsec.org/projects/threat/classes/os_commanding.shtml] http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
*OWASP Guide, [http://www.owasp.org/index.php/File_System http://www.owasp.org/index.php/File_System#Includes_and_Remote_files]
*OWASP Testing Guide, [http://www.owasp.org/index.php/Testing_for_Directory_Traversal http://www.owasp.org/index.php/Testing_for_Directory_Traversal]
*OWASP PHP Top 5, [http://www.owasp.org/index.php/PHP_Top_5 http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution]
*Stefan Esser,
[http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html]
*[SIF01] SIFT,Sift Networks, Web Services: Teaching an old dog new tricks, [http://www.ruxcon.org.au/files/2006/web_services_security.ppt http://www.ruxcon.org.au/files/2006/web_services_security.ppt]
*[http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_Security_Policy]
*Microsoft - Programming for Partial Trust, [http://msdn2.microsoft.com/en-us/library/ms364059(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ms364059(VS.80).aspx]

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Insecure Direct Object Reference|useprev=PrevLink|prev=-Injection Flaws|usemain=MainLink|main=}}

Top 10 2007-Malicious File Execution

2008-02-26T11:34:44Z

Marius Quadflieg: /* Protection */ removed double word

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Insecure Direct Object Reference|useprev=PrevLink|prev=-Injection Flaws|usemain=MainLink|main=}}

Malicious file execution vulnerabilities are found in many applications. Developers will often directly use or concatenate potentially hostile input with file or stream functions, or improperly trust input files. On many platforms, frameworks allow the use of external object references, such as URLs or file system references. When the data is insufficiently checked, this can lead to arbitrary remote and hostile content being included, processed or invoked by the web server.

This allows attackers to perform:

*Remote code execution
*Remote root kit installation and complete system compromise
*On Windows, internal system compromise may be possible through the use of PHP’s SMB file wrappers
This attack is particularly prevalent on PHP, and extreme care must be taken with any stream or file function to ensure that user supplied input does not influence file names.

== Environments Affected ==

All web application frameworks are vulnerable to malicious file execution if they accept filenames or files from the user. Typical examples include: .NET assemblies which allow URL file name arguments, or code which accepts the user’s choice of filename to include local files.

'''PHP is particularly vulnerable''' to remote file include (RFI) attack through parameter tampering with any file or streams based API.

== Vulnerability ==

A common vulnerable construct is:

<code>include $_REQUEST['filename’];</code>

Not only does this allow evaluation of remote hostile scripts, it can be used to access local file servers (if PHP is hosted upon Windows) due to SMB support in PHP’s file system wrappers.

Other methods of attack include:

*Hostile data being uploaded to session files, log data, and via image uploads (typical of forum software)
*Using compression or audio streams, such as zlib:// or ogg:// which do not inspect the internal PHP URL flag and thus allow access to remote resources even if allow_url_fopen or allow_url_include is disabled
*Using PHP wrappers, such as php://input and others to take input from the request POST data rather than a file
*Using PHP’s data: wrapper, such as <code>data:;base64,PD9waHAgcGhwaW5mbygpOz8+</code>
As this list is extensive (and periodically changes), it is vital to use a properly designed security architecture and robust design when dealing with user supplied inputs influencing the choice of server side filenames and access.

Although PHP examples have been given, this attack is also applicable in different ways to .NET and J2EE. Applications written in those frameworks need to pay particular attention to code access security mechanisms to ensure that filenames supplied by or influenced by the user do not allow security controls to be obviated.

For example, it is possible that XML documents submitted by an attacker will have a hostile DTD that forces the XML parser to load a remote DTD, and parse and process the results. An Australian security firm has demonstrated this approach to port scanning behind firewalls. See [SIF01] in this chapter’s references for more information.

The damage this particular vulnerability causes is directly related to the strength of the sandbox / platform isolation controls in the framework. As PHP is rarely isolated and has no sandbox concept or security architecture, the damage is far worse for an attack than other platforms with limited or partial trust, or are contained within a suitable sand box, such as when a web app is running under a JVM with the security manager properly enabled and configured (which is rarely the default).

== Verifying Security ==

Automated approaches: Vulnerability scanning tools will have difficulty identifying the parameters that are used in a file include or the syntax for making them work. Static analysis tools can search for the use of dangerous APIs, but cannot verify that appropriate validation or encoding might be in place to protect against the vulnerability.

Manual approaches: A code review can search for code that might allow a file to be included in the application, but there are many possible mistakes to recognize. Testing can also detect these vulnerabilities, but identifying the particular parameters and the right syntax can be difficult.

== Protection ==

Preventing remote file include flaws takes some careful planning at the architectural and design phases, through to thorough testing. In general, a well-written application will not use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions), and will have firewall rules in place preventing new outbound connections to the Internet or internally back to any other server. However, many legacy applications will continue to have a need to accept user supplied input.

Among the most important considerations are:

*'''Use an indirect object reference map''' (see section A4 for more details). For example, where a partial filename was once used, consider a hash of the partial reference. Instead of :

<code><select name=”language”>
<option value=”English”>English</option></code>

use

<code><select name=”language”>
<option value=”78463a384a5aa4fad5fa73e2f506ecfc”>English</option></code>

Consider using salts to prevent brute forcing of the indirect object reference. Alternatively, just use index values such as 1, 2, 3, and ensure that the array bounds are checked to detect parameter tampering.3.

*'''Use explicit taint checking mechanisms''', if your language supports it. Otherwise, consider a variable naming scheme to assist with taint checking:
<code>$hostile = &$_POST; // refer to POST variables, not $_REQUEST</code>
<code>$safe[‘filename’]= validate_file_name($hostile[‘unsafe_filename’]); // make it safe</code>

Therefore any operation based upon hostile input is immediately obvious:
<code>WRONG: require_once($_POST[‘unsafe_filename’] . ‘inc.php’);</code>
<code>RIGHT: require_once($safe[‘filename’] . ‘inc.php’);</code>

*'''Strongly validate user''' input using "accept known good" as a strategy
*'''Add firewall''' rules to prevent web servers making new connections to external web sites and internal systems. For high value systems, isolate the web server in its own VLAN or private subnet
*'''Check user supplied that any files or filenames'''taken from the user for legitimate purposes cannot obviate other controls,be otherwise obviated, such as tainting including user supplied data in the session object, avatars and images, PDF reports, temporary files, and so on
*'''Consider implementing a chroot jail '''or other sand box mechanisms such as virtualization to isolate applications from each other
*'''PHP:''' '''Disable allow_url_fopen and allow_url_include''' in php.ini and consider building PHP locally to not include this functionality. Very few applications need this functionality and thus these settings should be enabled on a per application basis
*'''PHP: Disable register_globals and use E_STRICT to find uninitialized variables'''
*'''PHP: Ensure that all file and streams functions (stream_*)''' '''are carefully vetted'''. Ensure that the user input is not supplied any function which takes a filename argument, including:
<code>include() include_once() require() require_once() fopen() imagecreatefromXXX() file() file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file()</code>

*PHP: Be extremely cautious if data is passed to system() eval() passthru() or ` (the backtick operator).
*With J2EE, ensure that the security manager is enabled and properly configured and that the application is demanding permissions appropriately
*With ASP.NET, please refer to the documentation on partial trust, and design your applications to be segmented in trust, so that most of the application exists in the lowest possible trust state possible

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722]

== References ==

*CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95 (Eval injection), CWE-434 (Unrestricted file upload)
*WASC Threat Classification:
[http://www.webappsec.org/projects/threat/classes/os_commanding.shtml http://www.webappsec.org/projects/threat/classes/os_commanding.shtml] http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
*OWASP Guide, [http://www.owasp.org/index.php/File_System http://www.owasp.org/index.php/File_System#Includes_and_Remote_files]
*OWASP Testing Guide, [http://www.owasp.org/index.php/Testing_for_Directory_Traversal http://www.owasp.org/index.php/Testing_for_Directory_Traversal]
*OWASP PHP Top 5, [http://www.owasp.org/index.php/PHP_Top_5 http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution]
*Stefan Esser,
[http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html]
*[SIF01] SIFT,Sift Networks, Web Services: Teaching an old dog new tricks, [http://www.ruxcon.org.au/files/2006/web_services_security.ppt http://www.ruxcon.org.au/files/2006/web_services_security.ppt]
*[http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_Security_Policy]
*Microsoft - Programming for Partial Trust, [http://msdn2.microsoft.com/en-us/library/ms364059(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ms364059(VS.80).aspx]

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Insecure Direct Object Reference|useprev=PrevLink|prev=-Injection Flaws|usemain=MainLink|main=}}

User:Marius Quadflieg

2008-02-25T10:54:54Z

Marius Quadflieg: New page: Software Engineering Student - Fontys Hogeschool Venlo (NL) '''Blog:''' [http://www.portal4gamers.de www.portal4gamers.de] '''Email:''' marius at quadflieg dot name '''PGP Key:''' [http...

Software Engineering Student - Fontys Hogeschool Venlo (NL)

'''Blog:''' [http://www.portal4gamers.de www.portal4gamers.de]

'''Email:''' marius at quadflieg dot name

'''PGP Key:''' [http://pgp.mit.edu:11371/pks/lookup?search=0xD8168DB7&op=index 0xD8168DB7]

Testing for SQL Injection (OTG-INPVAL-005)

2008-02-25T10:50:09Z

Marius Quadflieg: Fixed a spelling error

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

An [[SQL Injection]] attack consists of insertion or "injection" of an SQL query via the input data from the client to the application. 
A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such shutdown the DBMS), recover the content of a given file present on the DBMS filesystem and in some cases issue commands to the operating system.

== Description of the Issue ==
SQL Injection attacks can be divided into the following three classes:
* Inband: data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page
* Out-of-band: data is retrieved using a different channel (e.g.: an email with the results of the query is generated and sent to the tester)
* Inferential: there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behaviour of the DB Server.

Independent of the attack class, a successful SQL Injection attack requires the attacker to craft a syntactically correct SQL Query. If the application returns an error message generated by an incorrect query, then it is easy to reconstruct the logic of the original query and therefore understand how to perform the injection correctly. However, if the application hides the error details, then the tester must be able to reverse engineer the logic of the original query. The latter case is known as "[[Blind SQL Injection]]".

== Black Box testing and example ==

=== SQL Injection Detection ===

The first step in this test is to understand when our application connects to a DB Server in order to access some data. Typical examples of cases when an application needs to talk to a DB include:
* Authentication forms: when authentication is performed using a web form, chances are that the user credentials are checked against a database that contains all usernames and passwords (or, better, password hashes)
* Search engines: the string submitted by the user could be used in a SQL query that extracts all relevant records from a database
* E-Commerce sites: the products and their characteristics (price, description, availability, ...) are very likely to be stored in a relational database.
The tester has to make a list of all input fields whose values could be used in crafting a SQL query, including the hidden fields of POST requests and then test them separately, trying to interfere with the query and to generate an error.
The very first test usually consists of adding a single quote (') or a semicolon (;) to the field under test. The first is used in SQL as a string terminator and, if not filtered by the application, would lead to an incorrect query. The second is used to end a SQL statement and, if it is not filtered, it is also likely to generate an error.
The output of a vulnerable field might resemble the following (on a Microsoft SQL Server, in this case):
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113
</pre>
Also comments (--) and other SQL keywords like 'AND' and 'OR' can be used to try to modify the query. A very simple but sometimes still effective technique is simply to insert a string where a number is expected, as an error like the following might be generated:
<pre>
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113
</pre>
A full error message like the ones in the examples provides a wealth of information to the tester in order to mount a successful injection. However, applications often do not provide so much detail: a simple '500 Server Error' or a custom error page might be issued, meaning that we need to use blind injection techniques.
In any case, it is very important to test *each field separately*: only one variable must vary while all the other remain constant, in order to precisely understand which parameters are vulnerable and which are not.

=== Standard SQL Injection Testing ===

Consider the following SQL query:

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

A similar query is generally used from the web application in order to authenticate a user. If the query returns a value it means that inside the database a user with that credentials exists, then the user is allowed to login to the system, otherwise the access is denied.
The values of the input fields are inserted from the user generally through a web form.
We suppose to insert the following Username and Password values:

$username = 1' or '1' = '1
$password = 1' or '1' = '1

The query will be:

<nowiki>SELECT * FROM Users WHERE Username= '1' OR '1' = '1' AND Password= '1' OR '1' = '1'</nowiki>
If we suppose that the values of the parameters are sent to the server through the GET method, and if the domain of the vulnerable web site is www.example.com, the request that we'll carry out will be:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1 </nowiki>

After a short analysis we notice that the query return a value (or a set of values) because the condition is always true (OR 1=1). In this way the system has authenticated the user without knowing the username and password. ''In some systems the first row of a user table would be an administrator user. This may be the profile returned in some cases.''
Another example of query is the following:

SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password')))

In this case, there are two problems, one due to the use of the parenthesis and one due to the use of MD5 hash function.
First of all we resolve the problem of the parenthesis.
That simply consist of adding a number of closing parenthesis until we obtain a corrected query. To resolve the second problem we try to invalidate the second condition.
We add to our query a final symbol that means that a comment is beginning. In this way everything that follows such symbol is considered as a comment.
Every DBMS has the own symbols of comment, however a common symbol to the greater part of the database is /*. In Oracle the symbol is "--".
Saying this, the values that we'll use as Username and Password are:

$username = 1' or '1' = '1'))/*
$password = foo

In this way we'll get the following query:

SELECT * FROM Users WHERE ((Username='1' or '1' = '1'))/*') AND (Password=MD5('$password')))

The url request will be:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo </nowiki>

Which return a number of values. Sometimes, the authentication code verifies that the number of returned tuple is exactly equal to 1. In the previous examples, this situation would be difficult (in the database there is only one value per user).
In order to go around to this problem, it is enough to insert a SQL command, that imposes the condition that the number of the returned tuple must be one. (One record returned)
In order to reach this goal, we use the command "LIMIT <num>", where <num> is the number of the tuples that we expect to be returned. The value of the fields Username and Password regarding the previous example will be modified according the following:

$username = 1' or '1' = '1')) LIMIT 1/*
$password = foo

In this way we create a request like the follow:

<nowiki>http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))%20LIMIT%201/*&password=foo </nowiki>

=== Union Query SQL Injection Testing ===
Another test to carry out, involves the use of the UNION operation. Through such operation it is possible, in case of SQL Injection, to join a query, purposely forged from the tester, to the original query. The result of the forged query will be joined to the result of the original query, allowing the tester to obtain the values of fields of other tables.
We suppose for our examples that the query executed from the server is the following:

SELECT Name, Phone, Address FROM Users WHERE Id=$id

We will set the following Id value:

$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

We will have the following query:

SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

which will join the result of the original query with all the credit card users.
The keyword '''ALL''' is necessary to get around the query that make use of keyword DISTINCT.
Moreover we notice that beyond the credit card numbers, we have selected other two values. These two values are necessary, because the two query must have an equal number of parameters, in order to avoid a syntax error.

=== Blind SQL Injection Testing ===
We have pointed out that exists another category of SQL injection, called Blind SQL Injection, in which nothing is known on the outcome of an operation. This behavior happens in cases where the programmer has created a customed error page that does not reveal anything on the structure of the query or on the database. (Does not return a SQL error, it may just return a HTTP 500).
 
Thanks to the inference methods it is possible to avoid this obstacle and thus to succeed to recover the values of some desired fields. The method consists in carrying out a series of booloean queries to the server, observing the answers and finally deducing the meaning of such answers.
We consider, as always, the www.example.com domain and we suppose that it contains a parameter vulnerable to SQL injection of name id.
This means that carrying out the following request:

<nowiki>http://www.example.com/index.php?id=1' </nowiki>

we will get one page with a custom message error which is due to a syntactic error in the query. We suppose that the query executed on the server is:

SELECT field1, field2, field3 FROM Users WHERE Id='$Id'

which is exploitable through the methods seen previously.
What we want is to obtain the values of the username field. The tests that we will execute will allow us to obtain the value of the username field, extracting such value character by character. This is possible through the use of some standard functions, present practically in every database. For our examples we will use the following pseudo-functions:

'''SUBSTRING (text, start, length)''': it returns a substring starting from the position "start" of text and of length "length". If "start" is greater than the length of text, the function returns a null value.

'''ASCII (char)''': it gives back ASCII value of the input character. A null value is returned if char is 0.

'''LENGTH (text)''': it gives back the length in characters of the input text.

Through such functions we will execute our tests on the first character and, when we will have discovered the value, we will pass to the second and so on, until we will have discovered the entire value.
The tests will take advantage of the function SUBSTRING in order to select only one character at time (selecting a single character means to impose the length parameter to 1) and function ASCII in order to obtain the ASCII value, so that we can do numerical comparison. The results of the comparison will be done with all the values of ASCII table, until finding the desired value.
As an example we will insert the following value for ''Id'':

$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1

that creates the following query (from now on we will call it "inferential query"):

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'

The previous returns a result if and only if the first character of field username is equal to the ASCII value 97. If we get a false value then we increase the index of ASCII table from 97 to 98 and we repeat the request. If instead we obtain a true value, we set to zero the index of the table and we pass to analyze the next character, modifying the parameters of SUBSTRING function.
The problem is to understand in that way we distinguish the test that has carried a true value, from the one that has carried a false value.
In order to make this we create a query that we are sure returns a false value.
This is possible by the following value as field ''Id'':

$Id=1' AND '1' = '2

by which will create the following query:

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'

The answer of the server obtained (that is HTML code) will be the false value for our tests.
This is enough to verify whether the value obtained from the execution of the inferential query is equal to the value obtained with the test exposed before.
Sometimes this method does not work. In the case the server returns two different pages as a result of two identical consecutive web requests we will not be able to discriminate the true value from the false value. In these particular cases, it is necessary to use particular filters that allow us to eliminate the code that changes between the two requests and to obtain a template. Later on, for every inferential request executed, we will extract the relative template from the response using the same function, and we will perform a control between the two template in order to decide the result of the test.
In the previous tests, we are supposed to know in what way it is possible to understand when we have ended the inference beacause we have obtained the value.
In order to understand when we have ended, we will use one characteristic of the SUBSTRING function and the LENGTH function.
When our test will return a true value and we would have used an ASCII code equals to 0 (that is the value null), then that mean that we have ended to make inference, or that the value we have analyzed effectively contains the value null.

We will insert the following value for the field ''Id'':

$Id=1' AND LENGTH(username)=N AND '1' = '1

Where N is the number of characters that we have analyzed with now (excluded the null value).
The query will be:

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'

that gives back a true or false value. If we have a true value, then we have ended to make inference and therefore we have gained the value of the parameter. If we obtain a false value, this means that the null character is present on the value of the parameter, then we must continue to analyze the next parameter until we will find another null value.

The blind SQL injection attack needs a high volume of queries. The tester may need an automatic tool to exploit the vulnerability.
A simple tool which performs this task, via GET requests on MySql DB is SqlDumper, is shown below.

[[Image:sqldumper.jpg]]

=== Stored Procedure Injection ===
Question: How can the risk of SQL injection be eliminated? 
Answer: Stored procedures. 
I have seen this answer too many times without qualifications. Merely the use of stored procedures does not assist in the mitigation of SQL injection. If not handled properly, dynamic SQL within stored procedures can be just as vulnerable to SQL injection as dynamic SQL within a web page. 
When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure. 

Black box testing uses SQL injection to compromise the system.
 
Consider the following SQL Server Stored Procedure: 
Create procedure user_login @username varchar(20), @passwd varchar(20) As
Declare @sqlstring varchar(250)
Set @sqlstring = ‘
Select 1 from users
Where username = ‘ + @username + ‘ and passwd = ‘ + @passwd
exec(@sqlstring)
Go
User input: 
anyusername or 1=1'
anypassword
This procedure does not sanitize the input therefore allowing the return value to show an existing record with these parameters. 
NOTE: This example may seem unlikely due to the use of dynamic SQL to log in a user but consider a dynamic reporting query where the user selects the columns to view. The user could insert malicious code into this scenario and compromise the data.
 
Consider the following SQL Server Stored Procedure: 
Create procedure get_report @columnamelist varchar(7900) As
Declare @sqlstring varchar(8000)
Set @sqlstring = ‘
Select ‘ + @columnamelist + ‘ from ReportTable‘
exec(@sqlstring)
Go
User input: 
1 from users; update users set password = 'password'; select *

This will result in the report running and all users’ passwords being updated.
 

== Related Articles ==

* [[Top 10 2007-Injection Flaws]]
* [[SQL Injection]]
* [[Avoiding SQL Injection]]

Technology specific Testing Guide pages have been created for the following DBMSs:

* [[Testing for Oracle | Oracle]]
* [[Testing for MySQL | MySQL]]
* [[Testing for SQL Server | SQL Server]]

== References ==

'''Whitepapers''' 

* Victor Chapela: "Advanced SQL Injection" - http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt
* Chris Anley: "Advanced SQL Injection In SQL Server Applications" - http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* Chris Anley: "More Advanced SQL Injection" - http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.nextgenss.com/research/papers/sqlinference.pdf
* Kevin Spett: "SQL Injection" - http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* Kevin Spett: "Blind SQL Injection" - http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf
* Imperva: "Blind SQL Injection" - http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* Ferruh Mavituna: "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

'''Tools''' 
* OWASP SQLiX- http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project
* Francois Larouche: Multiple DBMS SQL Injection tool - [[http://www.sqlpowerinjector.com/index.htm SQL Power Injector]] 
* ilo--: MySql Blind Injection Bruteforcing, Reversing.org - [[http://www.reversing.org/node/view/11 sqlbftools]] 
* Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net
* Antonio Parata: Dump Files by SQL inference on Mysql - [[http://www.ictsc.it/site/IT/projects/sqlDumper/sqldumper.src.tar.gz SqlDumper]] 
* icesurfer: SQL Server Takeover Tool - [[http://sqlninja.sourceforge.net sqlninja]]

{{Category:OWASP Testing Project AoC}}