Web application firewalls (WAF) are becoming more common in organizations of all sizes, thanks to PCI regulations requiring the use of WAFs or regular Web application security assessments. Many organizations are choosing to go with the one-time cost and annual maintenance fees associated with a WAF solution because it is always on. Economically, the decision makes sense since a Web app assessment is only a snapshot in time compared to a WAF, but WAFs cannot understand the complexities of an application's logic as a human being who is testing the application.

The problem is that outrageous claims are often found in WAF vendors' marketing materials that make buyers think a WAF is the silver bullet to preventing Web application compromises. I've seen examples that include how one WAF can stop all common application vulnerabilities, and that implementing a WAF is an adequate substitution for a thorough code review. Of course, what they don't tell you is just how much they can't detect.

A recent conversation among friends centered on a security breach at a security vendor that, ironically, just happens to also produce a commercial WAF. Public details stated the breach was through a website that ultimately led to the exposure of customer data. As if on cue, one friend mentioned that WAFs are never a permanent solution, which prompted another friend to ask, "What is?" My response? Three words: Fix the vulnerabilities.

Of course, that wasn't what he was looking for. He wanted a more detailed answer, so I unleashed one, and what I wanted to convey through my answer was that my "fix the vulns" wasn't a quick, generic security consultant answer. Instead, it was based on years of front-line experience securing a large environment and fighting the proliferation of poorly coded Web apps.

The tiresome phrase "there is no silver bullet for security" has become old and boring, but it still holds true to this discussion. (Yes, I know. I used it above.) As much as the marketing folks will try and convince you that their WAFs will protect your vulnerability-riddled Web app, there's no way that a WAF can understand all of your app's logic. Because, when they say that it protects against all common vulnerabilities, do they mean logic flaws, too? I doubt it.

Personally, I'm pretty sure logic flaws fall within the common category. The problem is they are often missed because automated scanners cannot detect them easily like the more well-known vulnerabilities, such as cross-site scripting and SQL injection. Similarly, a WAF will miss them because it's not possible to write a regular expression to catch a logic flaw.

So what's a SMB to do to protect its Web applications? Well, for one, fix the vulnerabilities! I say that partially in jest, but it's important to emphasize the need for developers to follow secure coding practices and have that code reviewed for vulnerabilities. My good friend, Kevin Johnson, recently gave a webcast for SANS called "Ninja Developers: Penetration Testing and Your SDLC." In the webcast, Kevin provides good advice on how developers can perform basic penetration techniques during development using tools like w3af to help find flaws before they make it to production.

Unfortunately, vulnerabilities will still make it through QA, and that's where the good, ol' defense-in-depth approach becomes key in helping defend against and detect attacks. A WAF can provide basic protection against "common" attacks and also act as an intrusion detection system (IDS). Log monitoring provides a layer critical for detecting and responding to anomalies that could indicate a successful attack. And don't forget that the underlying Web service and operating system needs to be patched as soon as patches become available.

I still stand by my statement -- fix the vulnerabilities -- but that does not in any way nullify the fact that best practices, like those just mentioned, should be followed. Just as it is impossible for a WAF to protect against all vulnerabilities a Web application might suffer, it's difficult for a penetration tester to find all vulnerabilities.

John Sawyer is a Senior Security Analyst with InGuardians. The views and opinions expressed in this blog are his own and do not represent the views and opinions of his employer. He can be reached at [email protected]