Hacker News Reader

Comment by lta | Hacker News Reader

I'm still strongly suspecting this whole WAF thing is mostly complete bullshit intended for projects doing security works mostly from spreadsheets.

Could someone with a proper background in security confirm or invalidate my suspicion ?

View on HN

I'd generally confirm that suspicion: https://www.macchaffee.com/blog/2023/wafs/

WAFs have a few valid uses in my opinion: "virtual patching" and the ability to create custom rules such as blocking/challenging/rate limiting obviously bad traffic. But the giant rulesets are actively harmful IMO. "Defense in depth" is not a valid justification for doing something actively harmful to both your users and the time budget of your security team.

+1 Absolutely. (Source: Original author of ModSecurity.)

Just wanted to say that it's a great blog post, thanks for writing it!

You are correct. Actual security needs to be inherently part of the application; you can't get it just by slapping something in front of it. And the way most WAFs work is basically just a fancier version of what https://thedailywtf.com/articles/Injection_Rejection does, which is horrifically bad on sites where people try to discuss HTML or SQL.

A properly configured WAF is arguably necessary to maintain SLAs on an API available on the web. Bad actors will hammer any open API endlessly unless the API shows signs of defense. This can affect connection latency for good users and cost for the business. Why would you ever bother processing (and cause server and database load and charges) for a million bogus login or search requests if the WAF can handle it automatically and basically for free?

Most bad actors are looking for easy targets and will move on when seeing minimal defenses. If we want to continue enjoying an open and accessible internet where any client that speaks the protocol can connect, then WAFs are an integral part of maintaining that public service.

In addition to defense-in-depth—simply adding a bunch of imperfect layers and acknowledging that no individual layer like this is all that effective on its own—there’s a component of creating signal: it can be pretty trivial for a motivated attacker to bypass a WAF, however it may not be trivial to do so without creating a paper trail of event logs, which can be used to trigger automated blocks or escalate alarms for a human to intervene.

Well not entirely because you always want defense in depth. Let’s say you are running 20 apps and 10 of them have security vulnerabilities like RCE.

Testing and deploying patches takes time probably you cannot just update 10 apps at once with single click.

Deploying WAF rule should cover that.

I mean ... You're not completely wrong, but you're not completely right either. For context: I've been working full-time in security for 15 years and on the fringes (reversing) for many more.

WAFs in and of themselves provide virtually zero security. They can block naive attacks -- catching the most obvious payloads -- and act as an early-warning signal that an attack may be underway (though the SNR on this is awful). But frankly, this is far less important in practice than the fact that it just makes things more difficult and annoying for attackers. Enough so that it can make a semi-attractive target into a no-go.

This is like defense-in-depth, but instead of layering protections in place so that the holes in the swiss cheese don't like up, you're making the cheese smell awful enough to ignore the juicy apple behind it.

If you're a valuable enough target, they're gonna go for the apple regardless of how bad the cheese is. ... And this analogy may have gotten away from me.

WAFs aren't bullshit but have limitations - they're effective against known attack patterns (SQLi, XSS) but can be bypassed with sophisticated techniques. They're best as one layer in a defense-in-depth strategy, not a complete security solution.

Reply on news.ycombinator.com