01:14 PM
Connect Directly

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
Current Issue
Dark Reading Tech Digest September 7, 2015
Some security flaws go beyond simple app vulnerabilities. Have you checked for these?
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-05
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-9750, CVE-2014-9751. Reason: this ID was intended for one issue, but was associated with two issues. Notes: All CVE users should consult CVE-2014-9750 and CVE-2014-9751 to identify the ID or IDs of interest. All references and d...

Published: 2015-10-05
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-9750, CVE-2014-9751. Reason: this ID was intended for one issue, but was associated with two issues. Notes: All CVE users should consult CVE-2014-9750 and CVE-2014-9751 to identify the ID or IDs of interest. All references and d...

Published: 2015-10-05
ntp_crypto.c in ntpd in NTP 4.x before 4.2.8p1, when Autokey Authentication is enabled, allows remote attackers to obtain sensitive information from process memory or cause a denial of service (daemon crash) via a packet containing an extension field with an invalid value for the length of its value...

Published: 2015-10-05
The read_network_packet function in ntp_io.c in ntpd in NTP 4.x before 4.2.8p1 on Linux and OS X does not properly determine whether a source IP address is an IPv6 loopback address, which makes it easier for remote attackers to spoof restricted packets, and read or write to the runtime state, by lev...

Published: 2015-10-05
Omron CX-One CX-Programmer before 9.6, CJ2M PLC devices before 2.1, and CJ2H PLC devices before 1.5 rely on cleartext password transmission, which allows remote attackers to obtain sensitive information by sniffing the network during a PLC unlock request.

Dark Reading Radio
Archived Dark Reading Radio
What can the information security industry do to solve the IoT security problem? Learn more and join the conversation on the next episode of Dark Reading Radio.