SQL Injection







Risk Rating:


As the name suggests, this vulnerability type deals with injecting SQL statements into database queries made by the web application to its backend database. Depending upon the database type and configuration, this may allow an attacker to either enumerate the entire contents of a database or even gain the ability to run system-level commands on the database server possibly leading to a full system compromise. There are two types of SQL injection vulnerabilities: normal and blind.

Normal SQL injections arise when an attacker is able to force the web application into revealing the SQL statement, or part of the statement, that is being made by the web application to the backend database. This is generally achieved by forcing the web application to produce an error that discloses SQL information, as shown in Figure 13-4. This information is extremely helpful to attackers since it assists them in creating a SQL injection exploit for the specific web application and database. Normal SQL injection may also allow the results of the SQL injection to be returned within the web response, possibly allowing the database contents to be dumped or the output of a command to be returned.

The difference between normal and blind SQL injection is that blind SQL injections do not reveal any part of the SQL statement or SQL results to the attacker, meaning that the database contents or command output are unable to be dumped within the returned web response. Blind SQL injection does, however, leak side effects of successful and failed SQL injections. This may simply be a different page or message being returned when a successful SQL injection takes place or having the web server pause for a specified number of seconds before returning the page to indicate a yes or no answer to the query.

So, as an example, let's say that the web application we are attacking is using PHP with a MySQL database. The code to perform the login process may contain a SQL statement similar to the following:

$success = "SELECT * FROM usertab WHERE user = $inputuser AND pass = $inputpass"; if ( $success != "") { allowLogin();

Figure 13-4 SQL injection forces an error revealing part of the SQL statement.

An attacker may then be able to bypass the authentication mechanism for the web application by setting the inputuser and inputpass fields of the login page to the following values:

So why does this cause the authentication mechanism to be bypassed? Well, let's analyze the resulting SQL statement after these values have been inserted:

SELECT * FROM usertab WHERE user = jdoe AND pass = xxxx OR 1=1 #

The hash symbol in MySQL is the comments symbol and causes the remainder of the line to be ignored. This is often used to comment out any trailing SQL that may exist in the SQL query. The 1 = 1 section causes the statement to always return true, resulting in the user being logged into the web application without knowing the password. This can have absolutely massive implications if the web application is highly sensitive, such as an Internet banking application, since the attacker may now be able to enumerate all of the bank's user accounts and bypass authentication mechanisms to access them.

SQL injection can also be used to dump database contents. This type of vulnerability is often found within web page search boxes. As a simple example, if you type hello in a search box, you get all searchable pages within the database containing the word hello. However, if you type the MySQL wildcard character % in a vulnerable search box, instead of getting all searchable pages containing a percent sign, the database interprets the percent sign as a wildcard character and every single searchable page within the database is returned. More advanced injections can be used to concatenate additional data onto the response to enumerate the database contents within other tables.

Blind SQL injection, however, does not allow you to dump the database contents directly. Traditional blind SQL injection requires a brute-force approach where the attacker injects a SQL query that tells the database to perform a certain action based on whether the query answer is true or false. As an example, the query could construct a SQL request that asks, "If the first character of the database username is an A, then wait for ten seconds before returning." If the web page is returned immediately, then the attacker knows the query answer was false, and he or she would then need to submit a second query asking if the first character of the database username was B, and so on. If the web page takes around ten seconds to return, then the attacker has enumerated the first letter of the database username. The attacker can repeat this for the second letter, then the third letter, and so on, until he or she has determined the entire database username. This same technique can be used to enumerate any type of information within the database. As you can imagine, this technique isn't exactly stealthy since it could take thousands of requests to determine just the database username, let alone the entire contents of a database table.

A more advanced and far more effective technique has been developed where a normal or blind SQL injection vulnerability can be exploited and have the results of the query tunneled out of the organization via DNS requests using the attacker's domain, as shown in Figure 13-5.

Let's say the attacker is attempting to enumerate all of the credit card numbers within a database. The attacker constructs a complex SQL injection exploit that will dump the database contents and then use this data to form DNS requests to the attacker's domain. In Step 1, the attacker injects the query into the web application, which then passes the SQL injection back to the backend database, as shown in Step 2. This query is then executed on the database, in Step 3, which dumps the credit card details. The attacker's query then grabs each credit card number and makes a series of DNS requests in the form creditcard1.attacker.com, creditcard2.attacker.com, and so on. Since the database server is configured to use the organization's DNS server, these DNS requests are sent via the corporate DNS server, in Step 4, out to the attacker's DNS server, in Step 5. The attacker's DNS server has been specifically created to strip the domain off the request and display the credit card numbers that have been smuggled out in the subdomain.

This SQL injection technique allowed the attacker to enumerate the contents of the database with a single query and did not depend on whether the attacker used a normal or blind SQL injection. This technique is much more covert, which only requires that the database server is configured to point to a valid DNS server.

3. Database executes injected query and uses the resulting data to perform DNS queries

1. SQL injection with DNS tunneling payload



DNS server with DNS tunneling awareness

1. SQL injection with DNS tunneling payload

6. Attacker's DNS server strips database contents out of DNS requests

5. DNS requests to attacker's domain containing database information as subdomain

DNS server with DNS tunneling awareness

2. SQL injection with DNS tunneling payload

Web server

2. SQL injection with DNS tunneling payload

4. DNS requests to attacker's domain containing database information as subdomain

Figure 13-5 SQL injection attack that tunnels query results out via DNS requests

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook

Post a comment