Understanding the Importance of SQL Injection

When you consider what databases offer attackers, it is easy to conclude that the primary target for malicious attackers might be obtaining the data in the database; however, SQL injection offers more than just the data. SQL injection enables the attacker to run arbitrary commands in the database, and sometimes as a high privilege user . Also, it is becoming more common to find databases on client machines as well as on servers, such as for indexing context. This means the number of target machines is also increasing. The following are some additional attacks that SQL injection bugs can lead to:

• Disclose sensitive information   If the database contains sensitive user data, a SQL injection bug can enable an attacker to obtain this data. An attacker might be able to cause a SQL injection bug to return more information than was intended.

• Tamper with data   SQL injection can enable an attacker to create, delete, or modify data already in the database, such as tables, stored procedures, and records.

• Run SQL commands with an elevated privilege   Once an attacker is able to inject SQL commands, the attacker might be able to run other SQL commands at an elevated privilege level. For instance, a stored procedure generally executes under the context of the caller. In an application, this context becomes the user account the application uses to connect to the SQL server. This can even be the System Administrator (sa) account, which would allow the attacker to execute any SQL command. In Microsoft SQL Server 2005, developers can create stored procedures that can be executed as the OWNER or some other user context using the EXECUTE AS clause.

• Execute arbitrary commands on the computer running SQL Server   A lot of computers running SQL Server have the ability to execute commands on the server itself. For instance, SQL Server has an extended stored procedure called xp_cmdshell that allows callers to execute system commands. If your database server is running as a high privilege user, such as Local System, the attacker will be able to execute those commands if there is a SQL injection bug.

• Gain access to the back-end network   Most network configurations allow access only to a front-end Web server and do not allow direct access to the database on the back-end network. When attackers are able to exploit a SQL injection bug, they are essentially running their code on the back-end server. Depending on the network configuration, not only can the attacker access the SQL Server, but also potentially other machines on the same back-end network. Imagine the damage attackers could do if they gain access to your intranet.

SQL injection vulnerabilities are extremely beneficial for attackers, regardless of the value of the data in the database. Finding the bugs efficiently requires assessing the vulnerability of each application and feature, discussed next , and knowing how to test, which is discussed later.

Assessing the Vulnerability of Applications

Web applications are not the only type of applications vulnerable to SQL injectionlots of other systems might also use a database to store data. If the application uses any data supplied by the attacker (or any untrusted source, such as a client receiving a response from a server or vice versa) when querying a SQL database, it is potentially vulnerable to SQL injection attacks.

Remember that your application might use data from multiple locations. For instance, if you are testing a Web application, the query string or the forms POST data might not be the only data the application uses to build a SQL query. The application might also use data from the requests headers, such as the Cookie, User-Agent, or Referer value. Because an attacker can specify data in the request, the application cannot trust any part of the input.

Some applications might store untrusted input in the database, and then later use the stored untrusted data to form part of a SQL statement. Examples might include a logging system or e-mail server. Imagine you have a logging system that records every request to the server, whether the request is successful or not. An application uses the data recorded to build reports so the administrator can determine which pages visitors view the most. If the data is stored in a back-end database and is used in SQL queries, an attacker could have sent malformed requests to the server that later cause SQL injection when the administrator views the reports of the logging system. This type of time-delayed attack requires the attacker to understand the system fairly well to craft input to cause an exploit. Normally, this attack would likely be considered a low risk; however, it is still possible, especially if the attacker is able to gain information about how the application interacts with the database.

One way to get a sense for which types of applications and features are vulnerable is to research where SQL injection bugs are found. The security vulnerabilities reported on Bugtraq ( http://www.securityfocus.com ) include several examples of SQL injection vulnerabilities found across many different applications. For instance, on February 16, 2006, someone who goes by the name sp3x from SecurityReason.com reported a SQL injection bug in PHPNuke.PHPNuke is a Web portal system that allows users to add articles or stories in an automated fashion to a Web site. It is written in PHP and supports different SQL databases, such as MySQL, mSQL, PostgreSQL, ODBC, ODBC_Adabas, Sybase, and Interbase, to store the users data. By supplying a single quotation mark in the applications Nickname field in the Your_Account module, an attacker was able to inject SQL statements, thus allowing an attacker to log on as any user without using the users password. To read more about this vulnerability refer to http://www.securityfocus.com/archive/1/425173 .