Opinion: Why application-layer defenses belong in the applications

Computerworld - I know that chances are no one rushed to remove all SQL injection vulnerabilities from their Web applications after I warned in my column last month how serious they can be. I know that most people, even if they recognized the importance of the vulnerability, would consider how much work was involved and conclude that there must be an easier way. Perhaps they'd think that their network intrusion-detection system (NIDS) could handle the job.

Well, I'm back this month to puncture that balloon.

NIDSs are largely ineffective against a determined attacker using techniques like SQL injection attacks.

As I said last month, attackers love targeting SQL services because that's where some of the most interesting stuff resides in many applications. Now imagine a high-value target coupled with security tools that largely fail to detect attacks. How is this possible? Think back to my description of the dreaded "or 1=1" attack.

It's trivially easy to tell our NIDSs to look out for the "or 1=1" string. But don't be fooled, since "2=2" and "3=3" work equally well. For that matter, so do "foo=foo" and "xyzzy=xyzzy." See where this is going?

That's right, using static signature definitions -- like the ones used by many popular NIDS products today -- will fail every time, since you'd need to write an infinite number of signature strings to recognize every attack. And those "n=n" attacks are the most trivial of SQL injection attacks at that.

The core of the problem is that all network-based intrusion-detection tools lack the context to be able to effectively determine whether or not an HTTP request contains malicious inputs.

And let's not stop there -- there's another dark truth of the IDS world lurking about. You know how we security folks have been telling the software folks to use SSL encryption to secure sensitive data as it traverses the network? Well, encrypting the network traffic -- which is a good practice -- effectively puts a lens cap on our surveillance cameras. NIDS products cannot see inside an SSL-encrypted packet any more than our adversaries can.

By SSL-encrypting our sensitive data, we're robbing our NIDS sensors of the ability to look into the data for signs of malicious payloads. Even if they were capable of detecting SQL injection (and other attacks) all the time, SSL would prevent that from working.

So does that mean we should toss in the towel and stop using NIDS and SSL? Of course not. It does mean, though, that we need to be keenly aware of the strengths and the limitations of the technologies we're using.