Paid Advertising
web application security lab

WAFs - A Change of Heart

I’ve been auditing a website over the last few days that has been seriously compromised. The good news is that they are prepared and determined to fix the problem, the bad news is that they have so many potential holes it would take a small army to fix them all in a reasonable amount of time. I found myself saying something I really thought I’d never say - “What about a WAF?” There are two special circumstances that struck me about this situation that made me have a bit of a change of heart.

First of all, anyone who has read this site long enough knows that I’m pretty critical of WAFs in general, so I’m not here selling them or anything. They can represent a single point of failure in many applications, add additional complexity, have false positives and false negatives and require administrative overhead - not to mention the cost. But here is where I changed my mind. In this case the client had between 1,000-5,000 customer facing attack points to secure. There is no possible way they could fix that by hand in any reasonable timeframe.

Secondly, the attacker left malware on the system that was intended to infect the users of it (a la the superbowl hack). Like firewalls, WAFs could theoretically be used for egress filtering. Even during a complete compromise the system could prevent consumers from getting infected with any future malware that the system leaves for them. This assumes that it is not re-assembled via JavaScript (or other client side code), but in most cases it would at least slow down the rate of infection. So yah, I had a moment of weakness and let the three letters out of my mouth, but in this case, I think it’s justified.

5 Responses to “WAFs - A Change of Heart”

  1. cail Says:

    WAFs are a tool. You should always use the right tool for the right job. Loving or loathing a tool, and thus not using it when the job calls for it, is silly.

    If you have some personal vendetta against hammers, then you shouldn’t be surprised when hammers look like a viable choice given a bunch of nails to deal with. Using screwdrivers to deal with those nails is even dumber than not liking hammers in the first place.

    Everything can have its place. Even WAFs.

  2. RSnake Says:

    Yup, and in this case I think I’ve finally found a situation in which I agree that it’s the right tool (or at least it’s the only tool in existence that does that job required). So yes, you can consider me a convert, however, I still am positive there are better technologies to be built.

  3. Anonymous Coward Says:

    You’re leaving out the DoS vector of these WAFs - they make the site potentially far more vulnerable to DoS.

  4. lpilorz Says:

    I think WAFs are also a good tool as an additional layer of monitoring (not stopping) attacks, which allows following the attackers’ moves, and preparing to be one step ahead of them. That, of course, requires a LOT of logs reading, but there are some applications where the attack surface is so big that it can’t be just “fixed” ;)

  5. kuza55 Says:

    @Anonymous Coward

    Even if WAFs are more susceptible to DoS (I’m saying if, because I do’t know much about them) I don’t see why it is a bad reason to deploy them.

    If you have a choice of having a large amount of holes which you can’t plug fast enough, and have to deal with either having issues which are easily exploitable, or being easier to DoS….well, I’m not sure how choosing to leave the holes unprotected is a viable option at all.


    Do you know if the clients *are* actually doing egress filtering, or is it just a possibility?

    Also, I’m curious; how would someone go about creating javascript which can reassemble an executable and then send the user a link to it?

    In Firefox (and Opera), it’s probably possible to redirect to a data: URL, but I can’t think of anything you can do on IE without requesting additional permissions from the user (or using a browser exploit). Cache poisoning might be a possibility, but I’m not sure how someone would be able to do *that* without triggering a filter.