Latest revision as of 17:35, 21 November 2012

SQL injection is a method of exploiting web applications performed over http or https to compromise the underlying database engine supporting dynamic content for the web application itself. Successful exploitation of an SQL injection vulnerability can result in the attacker gaining unfettered access to the database and can lead to further privilege escalation.

Typically, databases include things like (but not limited to):

• Authentication credentials
• Other identifying information about a user (like an IP address)
• Site configurations
• Site content and themes
• Communications between users within the site

This page will be updated relatively frequently, if it does not have the answer to your question, try the IRC, or check back later. In the IRC, we'll do our best to help you find the solution. Also, if you see missing things you'd like to contribute, don't hesitate to contact us.

Special thanks to hatter for his contributions to this article.

Cause(s) of vulnerabilities

Now is a good time for orientation with SQL servers and queries with the SQL primer, otherwise this text may prove be confusing. SQL Injection occurs when input from a user is directly passed to a SQL query by an application. In the context of web applications, user input comes from HTTP input.

• Un-sanitized user input - The developer made no effort to stop an injection attack
• Improper type handling - An integer sanitized or otherwise treated as a string, or vice versa
• Lack of output filtering - Output from a query that had user input passed to it is used as input in later queries when rendering the page
• Cookies and other "hidden" forms of communication in the HTTP request header are also processed as user input and can be considered attack vectors as well.

Potential target environments

A variety of environments are vulnerable to SQL injection. Nearly all of the interpreted languages and compiled languages could be used to write a vulnerable application. Databasing engines such as MySQL, PostgreSQL, Microsoft SQL Server, or Oracle could be used in a vulnerable application. It is important to note the HTTP server's version information along with the programming language in use by any application during testing. This in conjunction with Operating System information will assist during privilege escalation with injection.

Navigating unfamiliar databases without the C API

Nearly every modern databasing engine has an information_schema database or schema. Important tables that are part of information_schema include schemata, routines, columns, and tables.

MySQL database mapping

When outside of the C SQL API, access the data structure via the information_schema database.

• Show Databases equivalent:

SELECT schema_name FROM information_schema.schemata;

• Show tables equivalent:

SELECT TABLE_NAME FROM information_schema.tables WHERE table_schema=[database_name]

• Show fields equivalent:

SELECT column_name FROM information_schema.columns WHERE TABLE_NAME=[TABLE_NAME] AND table_schema=[database_name]

If the currently selected database is the only accessible database in the context of the vulnerable query, time can be saved by using the database() function or @@database environment variables, e.g. where table_schema = database() or where table_schema = @@database.

PostgreSQL mapping

PostgreSQL has the current_database() function in stead of the database() function.

• \dn equivalent:

SELECT schema_name FROM information_schema.schemata WHERE catalog_name=[DATABASE name]

• \dt equivalent:

SELECT TABLE_NAME FROM information_schema.tables table_type='BASE TABLE' AND table_schema=([schema_query]) AND catalog_name=[DATABASE name]

• \d [column_name] equivalent:

SELECT column_name FROM information_schema.columns WHERE TABLE_NAME=([table_query]) AND table_schema=([schema_query]) AND catalog_name=[database_name]

MS SQL mapping

An important note is that MS SQL is different when it comes to ordered single-cell selection.

• Listing Tables:

SELECT TABLE_NAME FROM information_schema.columns WHERE table_catalog=[database_name] GROUP BY TABLE_NAME ORDER BY TABLE_NAME ASC;

• Listing Columns:

SELECT column_name FROM information_schema.columns WHERE table_catalog=[database_name] AND TABLE_NAME=[table_query] GROUP BY column_name ORDER BY column_name ASC

Legacy databases

The information_schema database entered the open source community in MySQL version 5 and at the end of PostgreSQL Version 7.3; old and current versions of SQL engines contain their schema information in their administration databases. More information can be found on this by combining techniques listed here with the manuals and documentation.

PROCEDURE ANALYSE might come in handy.

It is typical that legacy database versions require privileged access for flexible mapping.

Databasing engines compared and contrasted in light of SQL injection

For compatibility purposes it is important to be mindful of what functions, environment variables, and tables are ubiquitous. When writing an automated attack tool, it is convenient to be able to use the same function in each SQL dialect, rather than choosing a function or variable per sql version.

• Additional similarities are added each update to the various database engines. Read the manuals for the affected engines to get an up-to-date view.
• Not all similarities or differences are documented here, only those relevant to SQL injection.
• Similarities and differences between database engines include table and column names, function names, environment variables, and statement syntax.

There are enough similarities that it is possible to have a degree of universal exploitation.

Information_schema

All of the databasing engines that presently have an information_schema collection have the following in common:

• The information_schema.tables table has a table_name column.
• The information_schema.columns table has both table_name and column_name columns.
• All of them have information_schema.routines and information_schema.schemata tables.

These database engines include PostgreSQL, MySQL, and MSSQL.

Functions & environment variables

Similarities between the different engines

MS SQL, MySQL, and PostgreSQL share the following:

• ascii()
• substring()
• count()
• lower()
• upper()
• BETWEEN ... AND ... conditional operator

MySQL and Postgres share the following:

• current_database()
• version()
• current_user
• LIMIT ... OFFSET ... clause syntax

MySQL and MSSQL share the following:

• database()
• @@version
• RLIKE clause for regular expressions

Other syntax

All of the databases share the same comparison operators, basic SELECT, WHERE, GROUP, and ORDER syntax. PostgreSQL and MySQL now also share the same LIMIT syntax}}

LIMIT [COUNT] offset [ROW TO START at]

Microsoft SQL does not have a LIMIT clause. In stead, sub-queries with SELECT TOP and ORDER BY clauses are used as a workaround. This makes for a less readable query and a more frustrating attack.

SELECT top 1 $column FROM (SELECT top $OFFSET $column FROM $table [WHERE clause] [GROUP BY clause] ORDER BY $column DESC) sq [GROUP BY clause] ORDER BY $column ASC

Capabilities

Different SQL databasing engines have different capabilities. As a result, there are advantages and disadvantages passed to an attacker for each limitation or unique piece of functionality that a SQL server may have to offer.

• MSSQL Has the ability to execute server side commands natively via xp_cmdshell. This feature can be enabled or disabled (remotely), and other functions exist to read/write to the windows registry.
• MySQL has the ability to read and write to files using the LOAD DATA and SELECT ... INTO OUTFILE ... statements as well as the load_file() function.
• PostgreSQL is the only databasing engine which supports trigger functions or other user-defined functionality added to a table in most procedural scripting languages (Perl,Python,Ruby). Because it supports stacked queries when combined with PHP, it is possible to use SQL injection to install an SQL backdoor or plugin.

Modern day SQL injection obstacles and countermeasures

Obstacles can occur on various layers of the OSI model. The software layer may filter the input during its processing. The network layer may be monitored by a NIDS or IPS and begin to drop traffic, add captcha verifications, or redirect to a honeypot. The HTTP server may also be running a Web Application Firewall. A researcher or penetration tester may find overcoming these obstacles difficult, but usually not impossible given enough dedication.

Configuration & environment challenges

Due to certain vulnerabilities requiring the use of boolean enumeration or timing attacks, many HTTP requests may be needed in order to successfully determine database contents, making the process of arbitrarily accessing data quite time consuming and noisy. Different databasing engines have different configuration settings, but usually include some form of maximum number of connections, maximum query size, maximum results size, maximum number of connections per user or client, and other resource restrictive options. Simply distributing a time consuming attack may only hinder the attacker by exhausting resources.

Database permissions and role-based-access control integration for the application may also play a large role in the amount of data an attacker may gather, as SQL injection only exploits in the context of the active connection to the SQL server that the vulnerable query executes within (ie. the username and password that the application is using for the query being exploited). Programming languages have different configurations for runtime as well, such as memory limits and maximum execution time when configured to run in conjunction with a webserver. Older versions of database servers may not have an information_schema database and may require a privileged user (like the database server administrator) to access any schema information.

IDS, IPS, and web application firewalls

Web application firewalls usually operate at the same layer as the HTTP server or web applications, and thus monitor the protocol and input layers. This is different than normal IDS, which are stand-alone pieces of software or hardware that inspect the network and the host layer. Most intrusion detection mechanisms built for web applications operate using signature-based detection. Therefore, as long as an attack does not match a signature, it will slip by most of them.

Common web application firewall HTTPD modules

• Mod_Security (Apache)
• Naxsi (Nginx)
• ISAPI Filters (Microsoft IIS)

Common signatures use regular expressions that will match (and block) many common or simple testing techniques.

Improper sanitizing

Any time improper sanitizing takes place there is a potential for partial sanitizing, and may make the exploitation process highly difficult if not impossible.

Partial sanitizing

Partial sanitizing may affect any or more (unlisted here) of the following important syntax characters and result in them being encoded in some fashion, escaped, or removed entirely. In many circumstances, it is possible to craft injection queries without syntax characters, resulting in filter bypass and sometimes IDS evasion.

• The space character (or all whitespace)

Jump to sql injection without whitespace

• The single quote and double quote characters: ', "

Jump to sql injection without quotes

• The tag or "equals" comparative operators: <, >, and =

Jump to sql injection without tags

• The comma character: ,

Jump to sql injection without commas

• The parenthesis characters: ( and )

Deprecated sanitizing

PHP's addslashes() function (now deprecated) relied on the unhex() function. The goal of addslashes() was to add an escape (\) behind any single quotes (') entered into a string. When multi-byte character sets (or collations) are in use, this can cause a vulnerability to occur. If a valid multi-byte character ends in 0x5c (the escape), it is possible to circumvent the escape completely by placing the first byte of that character before the single quote. When unhex() is called against the now escaped single-quote, it sees the two bytes as a single character, allowing the quote (0x27) to escape the string unscathed. An example prefix for a non-utf8 character set's multi-byte prefix that accepts 0x5c as an ending is 0xbf, so one could use %bf%27 in a url to bypass the use of addslashes().

Basic remote tests for SQL injection vulnerabilities

There are a number of factors to take into consideration when analyzing a SQL injection vulnerability. These factors will determine methodology for successful exploitation. SQL injection vulnerabilities are typically either standard injection vulnerabilities, error-based vulnerabilities, or blind vulnerabilities, blind being the most difficult of the three.

• Standard vulnerabilities - The page can be exploited by using the UNION SELECT or UNION ALL SELECT statements to simply display selected data on the page.
• Error-based vulnerabilities - Error based vulnerabilities occur when verbose errors from the SQL databasing engine are enabled and displayed on the page. Thus, attackers may use things such as illegal type conversions to throw errors containing data.
• Blind vulnerabilities - Blind SQL injection vulnerabilities are not only the most difficult to exploit, but also the most time consuming. Timing attacks and boolean enumeration are the only methods of successful exploitation of select statements.

Injection points

An SQL injection vulnerability's type is determined by the location of the user input. $input is used as an example input variable in the queries below to illustrate their classifications.

• SELECT ... WHERE clause injection

$query = "select * from table where id=$input";

• SELECT ... LIMIT, OFFSET, ORDER BY, and GROUP BY clause injections

$query = "select * from table limit $input";
$query = "select * from table limit 1 offset $input";
$query = "select * from table order by $input";
$query = "select * from table group by $input";

• UPDATE ... SET clause injection

$query = "update table set var=$input";

• UPDATE ... WHERE clause injection

$query = "update table set var=value where column_name='$input'";

• INSERT ... VALUES clause injection

$query = "insert into table values(null,$input)";

Input testing

Vulnerabilities always stem from user input. In web applications, user input may come from a variety of places: forms, cookies, GET parameters, and other request headers. In order to test for vulnerabilities remotely, researchers test the urls, forms, and cookies associated with the site or software of interest.}}

Your first where clause injection

The most reliable of tests consist of boolean challenges that filter the results a query returns combined with arithmetic operators. Boolean challenges will return zero rows if conditions are not met, whereas they will return the same value if the conditions are met. This way researchers are able to determine vulnerability via a "true/false" test.

• In the first example (using $id) we have an unsanitized integer. The URI (uniform resource indicator) may look something like:

 /article_by_id.php?id=10

• A researcher could check that URI against:

 /article_by_id.php?id=10%20AND%201=1
 and
 /article_by_id.php?id=10%20AND%201=0

• When a page is vulnerable, the page on

 /article_by_id.php?id=10%20AND%201=1

will match the page on:

 /article_by_id.php?id=10

however the page at:

 /article_by_id.php?id=10%20AND%201=0

will have data (and likely the entire article) missing.

• In the second example, using $title, the same affect can be achieved on an unsanitized string with the following URI's: