Risk
11/2/2009
01:14 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Thwarting SQL Injection Threats

New Dark Reading report explores what database developers and database administrators can do about the pervasive SQL injection attack

[Excerpted from "SQL Injection: A Major Threat to Data Security", a new report published today in Dark Reading's Database Security Tech Center.]

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.

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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.