OWASP - User contributions [en]

Testing for SQL Injection (OTG-INPVAL-005)

2009-09-14T14:03:44Z

Muhaimin Dzulfakar: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

An [[SQL injection]] attack consists of insertion or "injection" of a 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 as shutdown the DBMS), recover the content of a given file existing on the DBMS file system and, in some cases, issue commands to the operating system.
SQL injection attacks are a type of [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

==Related Security Activities==

===Description of SQL Injection Vulnerabilities===

See the OWASP article on [[SQL Injection]] Vulnerabilities.

See the OWASP article on [[Blind_SQL_Injection]] Vulnerabilities.

===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.

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 OWASP Prevention Cheat Sheet Series article on [[SQL Injection Prevention Cheat Sheet | Preventing SQL Injection]]

[[Category:Security Focus Area]]
__NOTOC__

== 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 those 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 generally obtained from the user through a web form.
Suppose we 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 returns 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 parentheses and one due to the use of MD5 hash function.
First of all, we resolve the problem of the parentheses.
That simply consists of adding a number of closing parentheses 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 a comment.
Every DBMS has its own symbols of comment, however, a common symbol to the greater part of the database is /*. In Oracle the symbol is "--".
This said, 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 returns 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 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 operator "LIMIT <num>", where <num> is the number of the tuples that we expect to be returned. With respect to the previous example, the value of the fields Username and Password will be modified as follows:

$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 involves the use of the UNION operator. This operator is used in SQL injections to join a query, purposely forged by 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 queries that use the 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 there is another category of SQL injection, called [[Blind SQL Injection]], in which nothing is known on the outcome of an operation. For example, this behavior happens in cases where the programmer has created a custom error page that does not reveal anything on the structure of the query or on the database. (The page does not return a SQL error, it may just return a HTTP 500).
 
By using the inference methods, it is possible to avoid this obstacle and thus to succeed to recover the values of some desired fields. This method consists of carrying out a series of boolean 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 named id vulnerable to SQL injection.
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 to obtain is 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 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 a time (selecting a single character means to impose the length parameter to 1), and the 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 the ASCII table, until the right value is found.
As an example, we will use 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 example returns a result if and only if the first character of the field username is equal to the ASCII value 97. If we get a false value, then we increase the index of the 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 ASCII table and we analyze the next character, modifying the parameters of the SUBSTRING function.
The problem is to understand in which way we can distinguish tests returning a true value from those that return false.
To do this, we create a query that always returns false.
This is possible by using the following value for ''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 obtained response from the server (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 executed before.
Sometimes, this method does not work. If 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 templates in order to decide the result of the test.

In the previous discussion, we haven't dealt with the problem of determining the termination condition for out tests, i.e., when we should end the inference procedure.
A techniques to do this uses one characteristic of the SUBSTRING function and the LENGTH function.
When the test compares the current character with the ASCII code 0 (i.e., the value null) and the test returns the value true, then either we are done with the inference procedue (we have scanned the whole string), or the value we have analyzed contains the null character.

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 up to now (not counting the null value).
The query will be:

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

The query returns either true or false. If we obtain true, then we have completed inference and, therefore, we know the value of the parameter. If we obtain false, this means that the null character is present in the value of the parameter, and we must continue to analyze the next parameter until we 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 the MySql DB, is SqlDumper, which 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]]

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
* 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''' 
* [[:Category:OWASP SQLiX Project|OWASP SQLiX]]
* 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 A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.sourceforge.net
* icesurfer: SQL Server Takeover Tool - [http://sqlninja.sourceforge.net sqlninja]
* Pangolin: Automated SQL Injection Tool - [http://www.nosec.org/en/pangolin.html Pangolin]
* Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/

[[Category:FIXME|broken links

* Kevin Spett: "SQL Injection" - http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* Kevin Spett: "Blind SQL Injection" - http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf

* Antonio Parata: Dump Files by SQL inference on Mysql - [http://www.ictsc.it/site/IT/projects/sqlDumper/sqldumper.src.tar.gz SqlDumper] 

]]

Testing for MySQL

2009-09-14T14:00:42Z

Muhaimin Dzulfakar: /* References */

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

== Short Description of the Issue ==
[[SQL Injection]] vulnerabilities occur whenever input is used in the construction of a SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers. It allows for the execution of SQL code under the privileges of the user used to connect to the database.

''MySQL server'' has a few particularities so that some exploits need to be
specially customized for this application. That's the subject of this section.

== Black Box testing and example ==

=== How to Test ===
When an SQL injection vulnerability is found in an application backed by a MySQL database,
there are a number of attacks that could be performed depending
on the MySQL version and user privileges on DBMS.

MySQL comes with at least four versions which are used in production worldwide.
3.23.x, 4.0.x, 4.1.x and 5.0.x.
Every version has a set of features proportional to version number.

* From Version 4.0: UNION
* From Version 4.1: Subqueries
* From Version 5.0: Stored procedures, Stored functions and the view named INFORMATION_SCHEMA
* From Version 5.0.2: Triggers

It should be noted that for MySQL versions before 4.0.x, only Boolean or time-based Blind Injection attacks could be used, since the subquery functionality or UNION statements were not implemented.

From now on, we will assume that there is a classic SQL injection vulnerability, which can be triggered by a request similar to the the one described in the Section on [[Testing for SQL Injection (OWASP-DV-005)|Testing for SQL Injection]].

<nowiki>http://www.example.com/page.php?id=2</nowiki>

=== The Single Quotes Problem ===
Before taking advantage of MySQL features,
it has to be taken in consideration how strings could be represented
in a statement, as often web applications escape single quotes.

MySQL quote escaping is the following: 
''' <nowiki>'A string with \'quotes\''</nowiki> '''

That is, MySQL interprets escaped apostrophes (\') as characters and not as
metacharacters.

So if the application, to work properly, needs to use constant strings,
two cases are to be differentiated:
# Web app escapes single quotes (' => \')
# Web app does not escape single quotes (' => ')

Under MySQL, there is a standard way to bypass the need of single quotes, having a constant string to be declared without the need for single quotes.

Let's suppose we want to know the value of a field named 'password' in a record,
with a condition like the following:
password like 'A%'

# The ASCII values in a concatenated hex: 
#: password LIKE 0x4125
# The char() function:
#: password LIKE CHAR(65,37)

=== Multiple mixed queries: ===

MySQL library connectors do not support multiple queries separated
by '''<nowiki>';'</nowiki>''' so there's no way to inject multiple non-homogeneous SQL commands inside a single SQL injection vulnerability like in Microsoft SQL Server.

For example the following injection will result in an error:

1 ; update tablename set code='javascript code' where 1 --

=== Information gathering ===

==== Fingerprinting MySQL ====

Of course, the first thing to know is if there's MySQL DBMS as a backend.

MySQL server has a feature that is used to let other DBMS ignore a clause in MySQL
dialect. When a comment block ''('/**/')'' contains an exlamation mark ''('/*! sql here*/')'' it is interpreted by MySQL, and is considered as a normal comment block by other DBMS
as explained in [http://dev.mysql.com/doc/refman/5.0/en/comments.html MySQL manual].

Example:
1 /*! and 1=0 */

'''Result Expected:''' 
''If MySQL is present, the clause inside the comment block will be interpreted.''

==== Version ====

There are three ways to gain this information:
# By using the global variable @@version
# By using the function [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html VERSION()]]
# By using comment fingerprinting with a version number /*!40110 and 1=0*/
#: which means
<nowiki>if(version >= 4.1.10)
add 'and 1=0' to the query.</nowiki>

These are equivalent as the result is the same.

In band injection:

1 AND 1=0 UNION SELECT @@version /*

Inferential injection:

1 AND @@version like '4.0%'

'''Result Expected:''' 
''A string like this: '''5.0.22-log''' ''

==== Login User ====

There are two kinds of users MySQL Server relies upon.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html USER()]]: the user connected to the MySQL Server.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html CURRENT_USER()]]: the internal user who is executing the query.

There is some difference between 1 and 2.

The main one is that an anonymous user could connect (if allowed)
with any name, but the MySQL internal user is an empty name (<nowiki>''</nowiki>).

Another difference is that a stored procedure or a stored function
are executed as the creator user, if not declared elsewhere. This
can be known by using '''CURRENT_USER'''.

In band injection:

1 AND 1=0 UNION SELECT USER()

Inferential injection:

1 AND USER() like 'root%'

'''Result Expected:''' 
''A string like this: '''user@hostname''' ''

==== Database name in use ====

There is the native function DATABASE()

In band injection:

1 AND 1=0 UNION SELECT DATABASE()

Inferential injection:

1 AND DATABASE() like 'db%'

'''Result Expected:''' 
''A string like this: '''dbname''' ''

==== INFORMATION_SCHEMA ====
From MySQL 5.0 a view named [[http://dev.mysql.com/doc/refman/5.0/en/information-schema.html INFORMATION_SCHEMA]] was created.
It allows us to get all informations about databases, tables, and columns,
as well as procedures and functions.

Here is a summary of some interesting Views.
{| border=1
|| '''Tables_in_INFORMATION_SCHEMA''' || '''DESCRIPTION'''
|-
|| ..[skipped]..|| ..[skipped]..
|-
|| SCHEMATA || All databases the user has (at least) SELECT_priv
|-
|| SCHEMA_PRIVILEGES || The privileges the user has for each DB
|-
|| TABLES || All tables the user has (at least) SELECT_priv
|-
|| TABLE_PRIVILEGES || The privileges the user has for each table
|-
|| COLUMNS || All columns the user has (at least) SELECT_priv
|-
|| COLUMN_PRIVILEGES || The privileges the user has for each column
|-
|| VIEWS || All columns the user has (at least) SELECT_priv
|-
|| ROUTINES || Procedures and functions (needs EXECUTE_priv)
|-
|| TRIGGERS || Triggers (needs INSERT_priv)
|-
|| USER_PRIVILEGES || Privileges connected User has
|-
|}
All of this information could be extracted by using known techniques as
described in SQL Injection section.

=== Attack vectors ===

==== Write in a File ====

If the connected user has '''FILE''' privileges and single quotes are not escaped,
the 'into outfile' clause can be used to export query results in a file.

Select * from table into outfile '/tmp/file'

Note: there is no way to bypass single quotes surrounding a filename.
So if there's some sanitization on single quotes like escape (\') there will
be no way to use the 'into outfile' clause.

This kind of attack could be used as an out-of-band technique to gain information
about the results of a query or to write a file which could be executed inside the
web server directory.

Example:

<nowiki>1 limit 1 into outfile '/var/www/root/test.jsp' FIELDS ENCLOSED BY '//' LINES TERMINATED BY '\n<%jsp code here%>';</nowiki>

'''Result Expected:''' 
'' Results are stored in a file with rw-rw-rw privileges owned by
MySQL user and group.

Where ''/var/www/root/test.jsp'' will contain:
<nowiki>//field values//
<%jsp code here%></nowiki>

==== Read from a File ====

Load_file is a native function that can read a file when allowed by
filesystem permissions.

If a connected user has '''FILE''' privileges, it could be used to get the files' content.

Single quotes escape sanitization can by bypassed by using previously described
techniques.

load_file('filename')

'''Result Expected:''' 

''The whole file will be available for exporting by using standard techniques.''

=== Standard SQL Injection Attack ===

In a standard SQL injection you can have results displayed directly
in a page as normal output or as a MySQL error.
By using already mentioned SQL Injection attacks and the already described
MySQL features, direct SQL injection could be easily accomplished at a level
depth depending primarily on the MySQL version the pentester is facing.

A good attack is to know the results by forcing a function/procedure
or the server itself to throw an error.
A list of errors thrown by MySQL and in particular native functions could
be found on [http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html MySQL Manual].

=== Out of band SQL Injection ===

Out of band injection could be accomplished by using the [[#Write_in_a_File|'into outfile']] clause.
=== Blind SQL Injection ===
For blind SQL injection, there is a set of useful function natively provided by MySQL server.

* String Length:
*: ''LENGTH(str)''
* Extract a substring from a given string:
*: ''SUBSTRING(string, offset, #chars_returned)''
* Time based Blind Injection: BENCHMARK and SLEEP
*: ''BENCHMARK(#ofcicles,action_to_be_performed )''
*: The benchmark function could be used to perform timing attacks, when blind injection by boolean values does not yield any results.
*: See. SLEEP() (MySQL > 5.0.x) for an alternative on benchmark.

For a complete list, refer to MySQL manual - http://dev.mysql.com/doc/refman/5.0/en/functions.html

== References ==
'''Whitepapers''' 
* Chris Anley: "Hackproofing MySQL" -http://www.nextgenss.com/papers/HackproofingMySQL.pdf

'''Tools''' 
* Francois Larouche: Multiple DBMS SQL Injection tool - http://www.sqlpowerinjector.com/index.htm 
* ilo--: MySQL Blind Injection Bruteforcing, Reversing.org - http://www.reversing.org/node/view/11 sqlbftools 
* Bernardo Damele A. G.: sqlmap, automatic 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 
* Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/

[[Category:FIXME|link not working

'''Case Studies''' 
* Time Based SQL Injection Explained - http://www.f-g.it/papers/blind-zk.txt

]]