We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

The Mike Rothman Security Report

Peter Schooff

SQL Injection Rears Its Ugly Head Again

user-pic
Vote 0 Votes

There is nothing like becoming reacquainted with old friends, especially attack vectors that seem to rise from the dead and create mass hysteria and leave a trail of mayhem in its wake. No, Godzilla has not risen from the depths to stomp on Tokyo. It's the re-emergence of the granddaddy of all web application attacks, SQL injection.

What? You've never heard of SQL injection? Maybe it's just an old friend for those of us who have been in the security business for a long time. In fact, SQL injection attacks have been around for at least seven years. However, they didn't gain widespread attention until about five years ago, when first-generation web applications (based on Windows Active Server Pages, Java, and early PHP) started to hit the mainstream.

SQL injection had been put on the back burner for a while, as cross-site scripting and other attacks got more media coverage. But now it's back -- and with a vengeance. This month, a new wave of attacks (originating in China) used SQL injection in a new totally automated fashion. The attackers used Google to identify web applications using SQL Server as the back-end. Then they built an automated SQL injection engine to compromise the web sites and insert malware into the database of vulnerable sites. These sites would then spread the malware to unsuspecting visitors, who become bots and zombies. The attack was sneaky and very effective.

What's most disconcerting is that hundreds of thousands of web sites were vulnerable to this attack and got nailed. That means there are a lot of first-generation web sites still out there not using the fairly simple defenses that can prevent SQL injection. Before I get the cart before the horse, let me define the attack and then talk about the risks.

SQL injection is a security vulnerability that targets the database layer of a web application. It allows the attacker to "inject" rogue SQL statements into a form and execute commands against the database. That's right -- the attack can drop tables or access pretty much anything that is in there, even private data. On the bad scale, having an attack with access to your entire database is usually pretty bad.

So what to do? Basically, SQL injection can be addressed in a number of fashions. The reason the attack fell out of favor for a while is because many of the new web application frameworks have built in defenses. So Windows .NET and J2EE take precautions to make sure SQL statements can't be injected into application form fields. If you are rewriting your applications in the near term, then the problem will pretty much work itself out.

Yet, I understand rewriting an existing application is not usually the path of least resistance. So now you need to figure out if you are vulnerable. The easiest way to do that is to get an application scanner and run it against your sites to find out your exposure. There are lots of offerings, ranging from free (wikto) to enterprise class (from IBM and HP) to services that check for all sorts of application problems (White Hat Security).

These scans will let you know which applications are vulnerable and then you can go about fixing them. Remediation can come in a variety of flavors as well. The first and best approach is to fix the application. Make sure to only use parameterized SQL commands to ensure that user input doesn't make its way into the SQL calls.

You can also front-end your database-driven applications with a web application firewall, which can block SQL injection attacks before they ever get to the application. These also range from the free (ModSecurity) to the enterprise class (Imperva, Breach Security, F5).

There are tens of millions of applications out there, most of which have been built without any concept or care for secure coding practices. The ramifications of this laissez-faire attitude are crushing, given the viral nature of attack propagation nowadays. The stakes are going up and we need to keep pace.

Amazingly enough, many of the secure application requirements in the PCI DSS standard are derived from having to defend against SQL injection. The two main aspects of Requirement 6 are (drum roll, please): code reviews and web application firewalls. So if you protect any kind of cardholder data, you'll become very familiar with this kind of database attack -- and also how to prevent it.

Some old friends you don't really want to see again, like my entire high school class. But I suspect you'll be hearing a lot more about SQL injection in the near term, so fix your stuff now, before you become tomorrow's headlines.

ebizQ is proud to bring you Security Incite's Mike Rothman, who podcasts and writes on application security and related topics.

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT