Web Application Firewalls
While I was at DefCon 14 and talking to Dinis Cruz, he and I got into a discussion about the appropriate usage of a Web Application Firewalls (WAF). My biggest beef with WAFs are that they know nothing about the user in question. They are essentially stateless in any meaningful way regarding the user. As a result they have no insight into what a user means, what state they are in, and what the actual flow they are in does.
Dinis then articulated something I have had a really hard time explaining but completely agree with. He said, “WAFs are for dynamic patching.” He’s completely correct. One of the most difficult parts of administration is patching vulnerable applications because it can completely change how the site works. It could take weeks to identify the problem properly, more weeks to spin up a project to deal with it, more weeks to build it, more weeks to QA test it and then even more time to launch.
Of course, I’m being slightly dramatic, but in a large enterprise it really can be just about that bad, especially if the management doesn’t see the issue as a real security risk. WAFs have the ability to allow a single website administrator/security operations person to mitigate risks in real time, or even set up rules to catch large swaths of issues before they hit the site. Of course this is blind because it won’t know anything about the user state or anything else for that matter.
When I broke Sanctum’s Appshield product, I used it’s own ignorance against it. Appshield is really more of a host based IPS, but the problem stands. It really didn’t know anything about me as a user or the application itself. It was able to stop certain attacks but as long as I followed a patch that the application allowed I could exploit the system all day long. So instead of one CSRF, I would need 4 in quick succession. Easy enough.
Not that I am downplaying WAFs usefulness, because I do think they add value, but they aren’t capable of solving security issues, only mitigating the risk until the issue can be solved by your own engineering staff (which may be permanantly). Of course therein lies another problem where the company might end up swapping one WAF for another and since the underlying application remains unpatched the hole will re-appear. So as long as your company recognizes that the patch is only temporary and requires actual development resources and understands the load requirements (and the potential single point of failure and possible additional security risk of allowing another MITM), WAFs are a viable security solution.
Lots of caveats. From a purist security perspective (I am not a purist, by the way) WAFs have major issues, but from a business perspective, it’s definitely something worth thinking about.
August 10th, 2006 at 8:32 am
That’s pretty much how I see it. Another reason for WAFs is to “dynamically patch” commercial software or any software where the organization deploying it has no way of fixing vulnerable code even if they DO know about it.
I see many clients running old, badly coded, legacy web-apps. Often the company that provided the app is either out of business or does not provide support any longer.
Sure, the ideal answer is to update your apps to modern, more secure versions or find a way to patch the apps. But like you said, from a business perspective a WAF provides a way to mitigate some of the risk those apps introduce with minimal skill-set requirements. Even if only the low hanging fruit is taken care of there is still some inherent value added. Still though, there’s a fine line between advocation of WAFs and causing a false sense of security by being unrealistic about what they do and do not solve.
August 10th, 2006 at 11:07 am
Exactly. I’m in favor of web application firewalls, but I think you have to understand the actual benefit they provide. Like most traditional IDSs they have either signature based detection or anomaly based detection. There are distinct and well documented problems with each approach.
I remember when Rain Forrest Puppy was doing a lot of IDS evasion techniques. He was finding holes on a daily basis. When I started doing my own assessments on snort, I found all sorts of hokey signatures, like the fact that if you changed the GDI+ exploit from a .jpg extention to a .gif extention it would walk right through your IDS. It’s almost painfully bad.
At the same time it would still stop most people. It’s all about that 90% solution added on top of a layered security model. If you protect in depth, you’re less likely to find yourself exposed to real attacks. Theoretically sure, you’re still vulnerable, but the “hardness” of the attack goes up significantly.