We demonstrate how to execute advanced attacks against syntax and logic of the SQL language. Several interesting tricks involving SQL injection are presented. Finally, we discuss basic methods of protecting applications against SQL injection attacks.

SQL Injection attacks target the core of a web application: its database. Their most significant impact enables an attacker to retrieve, modify, or delete arbitrary data. It is a serious threat to any application with a database back-end and a threat that should be fully understood in order to develop adequate countermeasures.

 

Every web server administrator must acknowledge techniques that can be used to identify an SQL Injection vulnerability (see Tobias Glemser's Article SQL Injection Attacks with PHP and MySQL, hakin9 03/2005) and assess the scope of its risk. The basic methodology for an SQL Injection attack is to identify a potential vector, then exploit that vector with customized SQL queries - all through the web browser.

Identification of the potential for a vulnerability is important, but even more important is the ability to evaluate its impact. In some cases, a SQL Injection vector may offer nothing more than the capability to generate some syntax errors, such as trying to convert strings to numeric values. In other cases, the vector may enable the attacker to fully compromise a database's information. Although the examples refer to MySQL databases, the techniques apply to any database platform and, in most cases, can be applied without modification. The core of these techniques targets the SQL language. Certain database extensions merely make these techniques easier to accomplish.

To refresh the memory

SQL Injection tests can be classified into three categories based on which aspect of the query is targeted:

• attack the syntax of the query - insert common SQL characters with the intention of generating errors to identify potential attack vectors,

• attack the syntax of the language - target the SQL language itself in order to generate database errors or perform simple queries by manipulating language constructs and semantic identities,

• attack the logic of the query - rewrite the query to retrieve arbitrary data from tables to which developers did not intend access.

These techniques can be combined to assess a web application and determine its vulnerability to SQL Injection attacks. In the next sections the SQL Injection payloads are presented without the entire URL as an example. This makes it easier to understand the techniques without cumbersome parameters and text.

This is also because the injection of these payloads is quite simple. Given a URL of the form http://site/page.cgi?a=foo&b=bar, a SQL Injection attack replaces the vulnerable parameter's value with its payload: http://site/page.cgi?a=<SQL Injection payload>&b=bar. As a further reminder, one has to remember to encode spaces and other characters in the payload so that they do not disrupt the syntax of the URL.

Attack the syntax of the query

The single quote, while arguably the most popular character for identifying SQL Injection vectors, is by no means the only character necessary to generate a database error. This technique encompasses most fundamental tests for potential vulnerabilities by using SQL language metacharacters or formatting characters to disrupt the syntax of the original query. For example, the following statements cannot be parsed into valid queries because they have an ill-formed syntax due to an unterminated single quote:

• SELECT foo FROM bar WHERE a = ''';,

• SELECT foo FROM bar WHERE a = '/*;,

• SELECT foo FROM bar WHERE a = ';--;,

• SELECT foo FROM bar WHERE a = '#;.

While the most common example is the single quote character (ASCII 0x27), many characters can be used to disrupt the syntax including:

• unmatched parenthesis,

• semi-colon,

• comment delimiter - /*, #, or --.

Validation filters that only prohibit single quote characters (or some small set of characters) might prevent full exploitation of a vulnerability, but such filters are often inadequate. They may simply obscure more fundamental problems with the application's database connection architecture.

sum:

0 €