Perimeter
6/15/2011
01:47 PM
John H. Sawyer
John H. Sawyer
Commentary
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
Latest Comment: nice post
Current Issue
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-2014-1750
Published: 2015-07-01
Open redirect vulnerability in nokia-mapsplaces.php in the Nokia Maps & Places plugin 1.6.6 for WordPress allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the href parameter to page/place.html. NOTE: this was originally reported as cross-sit...

CVE-2014-1836
Published: 2015-07-01
Absolute path traversal vulnerability in htdocs/libraries/image-editor/image-edit.php in ImpressCMS before 1.3.6 allows remote attackers to delete arbitrary files via a full pathname in the image_path parameter in a cancel action.

CVE-2015-0848
Published: 2015-07-01
Heap-based buffer overflow in libwmf 0.2.8.4 allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted BMP image.

CVE-2015-1330
Published: 2015-07-01
unattended-upgrades before 0.86.1 does not properly authenticate packages when the (1) force-confold or (2) force-confnew dpkg options are enabled in the DPkg::Options::* apt configuration, which allows remote man-in-the-middle attackers to upload and execute arbitrary packages via unspecified vecto...

CVE-2015-1950
Published: 2015-07-01
IBM PowerVC Standard Edition 1.2.2.1 through 1.2.2.2 does not require authentication for access to the Python interpreter with nova credentials, which allows KVM guest OS users to discover certain PowerVC credentials and bypass intended access restrictions via unspecified Python code.

Dark Reading Radio
Archived Dark Reading Radio
Marc Spitler, co-author of the Verizon DBIR will share some of the lesser-known but most intriguing tidbits from the massive report