Tech Insight: SQL Injection Demystified

A Special Analysis For Dark Reading

Several high-profile hacks over the past year including those at Heartland, Hannaford Bros., and 7-11, all have had one thing in common: they were launched with a SQL injection attack.

Cross-site scripting (XSS) had been the king of Web attack techniques for some time, and for good reason -- the ability to steal user credentials, hijack active Web sessions and take action on behalf of a user without their knowledge is particularly nasty. But the classic SQL injection attack has regained the lead as the most popular of Web attacks. Most of all reported Web breaches the first half of this year, according to the new Web Hacking Incidents Database (WHID) report, were conducted via SQL injection. And SQL injection is one of the most common vulnerabilities in Web applications today.

SQL injection attacks take advantage of an application not validating input (like on Twitter and Facebook), or input into a form, such as a site search. The user's input is then incorrectly executed by the backend database server and can have a myriad of results. The simplest example is entering a single quote (') into a search field or login form, and receiving an error message that the SQL query failed.

The attack basically lets the bad guy take an ordinary input field and abuse it in ways that allows him to bypass authentication into the Website, manipulate the database to disclose large amounts of data, or access and control the database server itself.

SQL injection has grown in popularity over the last several years, thanks to not just the powerful results, but also the ease in which attacks can be carried out -- like the single quote example. All it takes to successfully exploit a SQL injection flaw is a Web browser. However, many tools have been created to make it easier to scan Websites for SQL injection vulnerabilities and attack them. Some examples are sqlmap (recently updated), sqlninja, Absinthe, and BSQL Hacker.

Not all SQL injection tools are designed for scanning and carrying out attacks. At DEFCON 17, Kevin Johnson and Justin Searle from InGuardians, along with Frank DiMaggio, announced a new project called Laudanum that takes a slightly different approach to SQL injection attack tools. Instead of releasing another scanning and exploit tool, they are publishing files that can be used as the payload to a SQL injection attack. They include functionality such as Web-based shells, DNS querying, LDAP retrieval, and more.

Successful SQL injection attacks don't always lead to compromise of the actual database server: often, the attacks instead result in complete exposure of the database contents, which could be anything from a simple listing of all users and their passwords, or much worse, all customer data including credit card information.

Depending on the rights of the database user account for the Web application, data manipulation within the database is also a possibility. The Asprox botnet is a good example of this: it inserted malicious links and iFrames into the source code of vulnerable Websites via SQL injection. The resulting changes caused visitors of the affected Website to be redirected to sites hosting malicious JavaScript that attempted to exploit and infect the user's Web browser.

The prevalence of SQL injection vulnerabilities and the ease in which they can be exploited begs the question of why aren't more companies finding the vulnerabilities and securing their systems accordingly. The tools exist for scanning and detecting the flaws -- and many of them are free and quite effective -- but for some reason, they just aren't being used proactively for detection before an attacker has the chance to exploit them.

Of course, detection with scanning tools is only one side of the problem. The key issue is how to prevent SQL injection vulnerabilities and thwart attacks. OWASP (Open Web Application Security Project) has an excellent document titled the "SQL Injection Prevention Cheat Sheet" that includes primary defense options like parametrized queries, stored procedures, and escaping all user input. Additional defenses included in the OWASP document are least privilege and whitelist input validation. The purpose behind the first two defensive approaches is to stop using dynamic SQL queries that accept user input. Instead, developers use prepared SQL statements that take the user's input as parameters, preventing an attacker from modifying the functionality of the SQL statement. The difference between parametrized queries and stored procedures is that the first is part of the application, while the latter lives in the database and is called by the application.

The third primary defense is to escape all user input, and according to the OWASP guide, this approach can be implemented within existing applications "with almost no effect on the structure of the code." In other words, if rewriting existing SQL statements as prepared statements or stored procedures is scary to your developers, escaping user input is the easy way out while still providing protection.

As added layers of defense that keep with good secure application coding practices, least privilege access should be enforced and all user input should be validated using a whitelist of valid input. For example, if the application only needs to read data from the database and only looks at fields containing numbers 1 through 9, then the database user account used by the application should only have read access to the tables necessary for the application to function. User input should be filtered to only allow numbers 1 through 9. While that sounds like common sense, it's a often common mistake by application developers.

Meanwhile, when you investigate a SQL injection attack, the most important thing is to have logging in place for the Web, application, and database servers. Having logs that show the attack request can help you understand exactly what the attacker was doing, while logs from the database server can indicate whether or not the attack was successful.

And having someone available who knows the application inside and out is very important. They can answer questions about what would happen if this query were successful, and whether or not the account used by the database would have privileges to do whatever the attacker was attempting. This is where having a good relationship between the security team and the developers is extremely important.

It is an easy vulnerability to exploit and tools exist that make it easy enough that practically anyone can do it, but with a little effort, companies can prevent the attacks if they follow the basic defense options recommended by OWASP.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.