Poison

Within a couple of hours, an experienced Internet attack specialist can bring your server infrastructure to its knees. In many cases, the barn door through which the attackers gain entry is a classic bug in a web application: an SQL injection vulnerability. SQL injection, which has been known for around 12 years, is still one of the hacker's most popular tools.

This article presents real-life examples of SQL injection attack vectors, explains how carelessness can cause them, and shows how far-reaching the impact can be. I will start by demonstrating these SQL attack techniques manually, then I'll show how to use the SQLmap tool to look for vulnerable code.

Typical Attack Vectors

One feature that nearly all web applications have in common is the connection to one or multiple databases. Whether it is used for retrieving email, shopping on the web, or reading news, there will always be at least one database back end. And, no matter which programming language the web application was written in, communication with the database always follows the same principle. The script stored on the server passes in the SQL queries to the database, evaluates the return values, and serves them up to the user.

Security holes in web applications can result from a lack of security awareness on the part of the developers. The larger issues mainly arise from a lack of input validation. The following PHP script, which is part of a popular login screen, demonstrates a typical programming error.

$query = "SELECT * FROM users WHERE user='" .
$_POST['username'] . " ' AND password=' " .
$_POST['password'] . " ' ";
$response = mysql_query($query) ;

The expected values are the username and password. The script checks whether the input data matches the credentials stored in the database. If the user is found in the database, and the password matches, the user is legitimate. The SQL statement that handles this is passed in as follows:

SELECT * FROM users WHERE user='...' AND password='...'

In other words, the two variables, user and password, are added to the database query. This approach works in theory, but imagine an attacker changing the query like this:

Password = ' OR 'a' = 'a'

The query to the database is now:

SELECT * FROM users WHERE user = 'Patrik' AND password = ' ' OR 'a' = 'a'

This SQL query first checks the OR condition and then the AND condition. The OR condition checks whether at least one of the two arguments is true – the logical question is whether 'a' = 'a', will always be true. The AND condition checks whether the username Patrik exists in the database: If this is the case, a value of true is returned. Because both arguments turn out to be true, the attacker is authenticated on the system without needing a password. Instead of simple strings, the attacker has injected SQL commands into the original query, which explains the term SQL injection.

You can prevent an attack of this kind by making sure that web applications validate all input and by using prepared statements instead of simple string concatenation. The scripting language then ensures that only desired data types, such as strings, are passed into the query.

Vulnerable

To demonstrate attack methods for SQL, the remainder of this article uses a potentially vulnerable lab environment comprising an XAMPP web server with a deliberately buggy application by the name of DVWA (Damn Vulnerable Web Application [1]). This web application is built with PHP and MySQL and specially designed for security specialists to gives users the option of testing various attacks on web applications in a legitimate way.

After installing Microsoft Windows Server 2003 and setting up the DVWA web application, the user first needs to log into the system via the login field with a username of Admin and a password of Password. DVWA offers three different difficulty levels that simulate different server security setting scenarios. To demonstrate SQL injection, you need to choose the Low setting in DVWA Security to make sure that all the security mechanisms that could prevent an SQL injection are disabled.

You can now choose the vulnerable module on the left in the tab. In this article, I will be using the SQL Injection module (Figure 1).

Figure 1: The SQL Injection module in the Damn Vulnerable Web Application.

Quotes

To check for a potential SQL injection vulnerability, you then enter a quote in the field. SQL injection is only possible if an application passes in user input to the server as part of a SQL query without checking the user input for metacharacters (backslash, apostrophe, quote, semicolon). In this case, the database returns the following error message:

You have an error in your SQL syntax;
check the manual that corresponds to
your MySQL server version for the
right syntax to use near ''''' at line 1

This is the first hint of a potential SQL injection vulnerability.