Perimeter
6/15/2011
01:47 PM
John H. Sawyer
John H. Sawyer
Commentary
Connect Directly
RSS
E-Mail
50%
50%

WAFs Have Benefits, But Are Not A Security Cure-all

WAFs can provide a good layer of defense against attacks, but they can't solve all Web app-sec problems the way vendors would like you to think

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 johnhsawyer@gmail.com

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-1032
Published: 2014-09-17
Cross-site scripting (XSS) vulnerability in the Euroling SiteSeeker module 3.x before 3.4.5 for EPiServer allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. NOTE: the provenance of this information is unknown; the details are obtained solely from third party inf...

CVE-2012-1417
Published: 2014-09-17
Multiple cross-site scripting (XSS) vulnerabilities in Local Phone book and Blacklist form in Yealink VOIP Phones allow remote authenticated users to inject arbitrary web script or HTML via the user field to cgi-bin/ConfigManApp.com.

CVE-2012-1506
Published: 2014-09-17
SQL injection vulnerability in the updateStatus function in lib/models/benefits/Hsp.php in OrangeHRM before 2.7 allows remote authenticated users to execute arbitrary SQL commands via the hspSummaryId parameter to plugins/ajaxCalls/haltResumeHsp.php. NOTE: some of these details are obtained from th...

CVE-2012-1507
Published: 2014-09-17
Multiple cross-site scripting (XSS) vulnerabilities in OrangeHRM before 2.7 allow remote attackers to inject arbitrary web script or HTML via the (1) newHspStatus parameter to plugins/ajaxCalls/haltResumeHsp.php, (2) sortOrder1 parameter to templates/hrfunct/emppop.php, or (3) uri parameter to index...

CVE-2012-2583
Published: 2014-09-17
Cross-site scripting (XSS) vulnerability in Mini Mail Dashboard Widget plugin 1.42 for WordPress allows remote attackers to inject arbitrary web script or HTML via the body of an email.

Best of the Web
Dark Reading Radio
Listen Now A Grown-Up Conversation About Passwords
A Grown-Up Conversation About Passwords