I can add to the list of attack vectors a case where the WAF introduced a reflected cross-site scripting vulnerability. The site it was supposedly protecting was blank, i.e. it just returned a 404 error or something. But just by appending a URL parameter with JS in it, the WAF would trigger and reflect the code. So I was able to build an outlook web app lookalike for phishing on a site with the domain of the company.

1. WAFs require entire requests to be buffered in order to be scanned before the server sees them. This can require lots of RAM.

2. WAFs scan requests with all sorts of hacky rules, which takes gobs of CPU time.

3. The hacky rules look for programming language syntax, for which the attackers can easily find alternative expressions to get around the rules.

4. ... yet, WAFs have high false positive rates.

5. All that kludgly processing is a security weakness. WAFs tend to be closed source behemoths written in low-level languages.

The question what is the alternative and the suggested alternative is that everyone become perfect security expert. It is even less likely to succeed than creating security-aimed software by professionals.

Consider what is the proportion of sites that are created by people who knows zero about security. Wordpress is like on 40%+ web sites (ridiculous).

WAFs unlikely to prevent targeted attacks, they don't have to to be useful. In practice, simple measures can prevent many common attacks.

I have to disagree here. You are making assumptions that every developer in an org will always do the correct thing and deploy code that won't be exploitable to SQL injections, XSS, file inclusion, etc... That's just not the case. I'm all for doing the correct thing, and not just performing security theater, but WAFs do offer some protection. You need multiple layers of security covering the holes that may left in other layers. And a WAF can be one of those layers of protection.

  socat - TCP4:192.168.2.100:1234

  socat TCP4-LISTEN:1234,fork,reuseaddr -

I think it's like a lot of things in computer security, in that system owners just don't want to be the slowest gazelle in the herd. If an attacker is mass-exploiting some new remote vulnerability, then maybe the WAF means that you're one of the lucky ones who doesn't get hit. And yes, that's a very big maybe there.

WAFs don't do much to prevent targeted attacks except to require the attacker to craft a WAF bypass. As you've shown.

(I'm exaggerating here, but only a bit)

The key is that they should mitigate specific vulnerabilities and ideally once the proper fix is deployed the rules are then removed from the WAF.

WAFs have near-zero value for things like trying to detect shell-code or generic SQL injections as they just turn into fuzzy bug injectors. Any real attacker will very quickly find a way to structure their exploit to avoid the heuristics.

WAFs also have minimal value for custom software. Because even if you use it to deploy a quick block for an exploit unless you are just blocking a whole endpoint the attacker will also likely find a way to work around it.

Yes, they can be trivial to bypass. And yes, they don't block everything. But also, yes, they can be very useful in some situations.

My employer's security team maintains a WAF, and while it may be frustrating at times (like when anti-directory-traversal rules broke page names with '...' in them) I mostly prefer that they continue to do so for two big reasons: script kiddies and botnets.

It doesn't matter that a bypass is trivial when in practice your attacker won't mutate their attack -- if the attacker was more sophisticated, the defence could be too, but if the attack is dumb then there's no point in a sophisticated defence.

Botnets mean that purely reputation-based defence is insufficient. The best defence to a distributed attack is one that's really cheap to evaluate. If all an attacker ever tries is to hit our homepage with a fixed user agent string, then all we need to do is block that UA from hitting our home page. A simple WAF entry is sufficient to block that particular attacker.

This precise example is indeed poorly-applied, as the system is intended to receive arbitrary text of arbitrary technical complexity. But I wouldn't mind the rule being applied to my team's endpoints, as we can be confident that anyone sending shell has malicious intent regardless of whether there's any chance that my services would try to execute the code (they won't).

So long as it is possible to bring down services without any effort, skiddies will keep trying to do that. And so long as we've people trying dumb attacks in infrastructure, dumb defences can have a worthwhile effect. And if the dumb defences start catching stuff they're not supposed to catch, like the example with '...', they're dumb enough that we can understand why they're doing that and if we can safely turn them off.