It has been the better part of a decade since SQL injection became a popular mode of attacking enterprises. But today's IT organizations are struggling more than ever with these broadsides against their data assets.

Just this week, an attack against the International Monetary Fund was whispered to be the result of SQL injection, though the claim is unconfirmed. More concrete evidence of splashy SQL injection attacks was registered this month in breaches at Sony and even the security firm Comodo.

What can your organization do to prevent potential damage from an SQL injection attack? Experts say it starts with doing a better job of securing the databases that these attacks target -- and the Web applications from which they originate.

"SQL injection attacks continue to be very low tech and very easy to carry out, and I think organizations still are struggling to figure out why they're so vulnerable," says Josh Shaul, CTO for database security vendor Application Security Inc.

Shaul, along with other database security experts, says the problem is a combination of factors, including poor coding practices, legacy code and legacy databases that haven't been hardened, and a false sense of security provided by Web application firewalls (WAFs).

"The Web application firewall is positioned as the solution to SQL injection, but the truth about the Web app firewall is it's only effective if you can program it with known vulnerabilities," Shaul explains. "If you can't tell it exactly what vulnerabilities you have, it really can't do anything for you. So a lot of organizations just buy a WAF and deploy it. They get this false sense of security that everything is cool when, in fact, their systems are still vulnerable."

WAFs have forced attackers to be a little more creative with how they construct their attack vectors, says Kyle Adams, architect and lead developer at next-generation WAF vendor Mykonos Software.

"And so began the race -- firewall vendors striving to create more effective signatures, and hackers relentlessly trying to find ways to evade the signatures," Adams says.

Adams believes the security industry has done an admirable job getting the word out about SQL injections, but the problem is so immense that holes still remain.

"As developers became more security conscious, better coding practices and input validation started to bolster protection into new and legacy applications," Adams says. "Efforts were also initiated in many companies to review and augment existing applications with input validation and more secure SQL statement construction.

"Unfortunately, it is extremely difficult to catch every possible hole," Adams continues. "So even with this increased effort, the insufficient security practices of the past bleed into more modern applications. This exposes obscure and difficult-to-identify SQL injection vulnerabilities -- which are just as powerful, but take a little longer to hunt down."

Even if organizations improve the secure coding and testing of new applications, there are still many more production applications that remain untested, notes Mandeep Khera, chief marketing officer for application security vendor Cenzic.

"We have seen a lot of progress in terms of people focusing on SQL injection testing," Khera says. "However, organizations are only testing a fraction of their apps -- and finding and fixing SQL injection vulnerabilities in a fraction of apps will give you fractional security.

"Partial testing is like partial heart surgery -- since your other arteries are blocked, you are still very vulnerable. What organizations need to do is to start facing the fact that they have to test all their applications -- and either fix the critical vulnerabilities, block those vulnerabilities, or take down the functionality until they are fixed. There are no shortcuts here."

Even more important, organizations need to stop seeing SQL injection attacks solely as a Web app problem, experts say. The reason why many of these attacks are so disastrous is that the database layer just behind the application is defenseless once the hacker gets a toehold.

"The main problem I see most of the time is that organizations run the database at the highest privilege level possible," says Daniel Clemens, owner of the security consultancy Packetninjas. "Then there's SQL injection and, boom, you can create your stored procedures, drop your own files on there, and then basically compromise the back-end database." Many organizations are also lax about locking down ingress and egress from the database, making it easier for attackers to move information off the database, he adds.

To help prevent damage from SQL injection vulnerabilities, organizations must harden their databases by reducing privileges, updating databases, and monitoring activity. Even when an attack slips through the WAF, it can often be detected through database activity monitoring, experts say. "DAM solutions that can monitor unsuccessful queries of low severity -- queries failing due to a missing or unknown object or syntax errors, which are symptomatic of a SQL injection attack -- can quite effectively detect an attack before the query succeeds to grab data illegally from the database," says Mel Shakir, CTO of database security vendor NitroSecurity.

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