Honestly, so many of these complaints about web application firewalls fly so far past the point that I'm not surprised folk don't understand them.
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.
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.