Thwarting SQL Injection Threats
New Dark Reading report explores what database developers and database administrators can do about the pervasive SQL injection attack
Every time you turn around these days, it seems there's news of yet another wide-scale attack perpetrated through SQL injection. Forensics have proven that the biggest breaches of the last several years—Heartland Payment Systems, Hannaford Brothers, and even TJX—were all made possible through blended attacks. And yet many IT experts within the enterprise aren't even aware of how pervasive these attacks truly are nor what to do about them, according to "SQL Injection: A Major Threat to Data Security" a new report published today by Dark Reading.
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
At its root, the basic SQL injection technique is made possible by the fact that the mushrooming number of new applications hitting the Web today touch some sort of database in order to offer users easy access to information.
In any typical front-end application, there is usually a means to interact with the database via some sort of search box. When users enter their search term into that box, the middleware essentially stuffs that term into a query that is run against the database in order to pull up the requested information from a particular category in the data store.
But if a knowledgeable malcontent writes certain SQL commands within that front-end search box, he or she often gets the middleware application to perform a completely different query against the database in order to gain far more access to information and to the database itself than the developer ever intended. Instead of a product search, for instance, an attacker could potentially get the application to retrieve credit card information stored within the database.
"That's the really basic idea of SQL injection, it's just typing stuff into the Web app and actually getting it to execute against the database," says Josh Shaul, vice president of product management for Application Security Inc., a database security company.
But hackers have actually managed to refine that very basic idea into quite sophisticated attacks. One of the most common is the automated mass injection. In these cases, hackers are writing automated crawler programs to search for Web applications vulnerable to simple SQL injection and then to install Java script redirectors into the databases behind public Websites.
"Basically, what these people are doing is they're trying to use legitimate Websites in order to attack innocent victims," says Tom Cross, a vulnerability researcher for IBM ISS X-Force.
These types of attacks actually make up the most in the growing volume of SQL injection attacks on the network today—a number that has skyrocketed over the past year. The number of daily SQL injections jumped by 50 percent from Q4 of 2008 to Q1 of 2009 and then nearly doubled during Q2 of 2009, according to IBM ISS X-Force research.
But perhaps even more troubling are the type of targeted SQL injection attacks that criminals are using to loot corporate data stores. In cases such as the Heartland Payment Systems breach, attackers use SQL injection as a foothold into a database server, from which they can launch other attacks deeper into better-protected network systems.
In order to protect against both mass injections and targeted attacks, organizations need to take a multifaceted approach, says Michael Howard, principal security program manager at Microsoft. "It's a combination of reducing attack surface, solid database administration and maintenance, as well as good, secure coding practices," Howard says.
On the coding side of the house, developers need to understand that they must filter SQL statements out of the input so that middleware does not send them to the database.
"If the application isn't doing that effectively, the database itself can't differentiate between SQL statements that are being issued by the application and SQL statements that are being issued by the attacker," Cross says.
For applications that already exist and may have vulnerabilities, Web application firewalls can help mitigate risks. But DBAs need appropriate layers of back-end security to add to the front-end Web application firewall. This means providing themselves with the visibility of monitoring tools to see how and when the application is accessing the database in order to perform forensics analysis and prevent future attacks once they see evidence of on-going malfeasance.
DBAs need to follow a number of other best practices, including patching their databasese properly, limiting functionality to only what is needed, and better managing passwords.
"Even the DBA can make a difference in terms of whether they're utilizing best practices in setting access controls," says Philip Lieberman, CEO of Lieberman Software, an account and password management firm. "The DBAs are really the core of this because they're really the protectors of the database."
To download the full text of the new Dark Reading report, click here.
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.