Tech Insight: SQL Injection Demystified
Attackers are using the old standby SQL injection en masse -- a look at the attack and how to protect your applications from it
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.
More Security Insights
- Forrester Study: The Total Economic Impact of VMware View
- Securing Executives and Highly Sensitive Documents of Corporations Globally
- Innovations in Integration: Achieving Holistic Rapid Detection and Response
- Optimize Your SQL Environment for Performance & Flexibility
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.
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.