[girst]

Cloudflare's and all other "Webapp Firewalls" are just snake oil. They can't know what transformations are done server-side on untrusted input, so you'll always (with enough time and determination) be able to craft a string that passes the WAF but exploits the backend.

Just a few examples: https://github.com/frizb/Bypassing-Web-Application-Firewalls

[ejcx]

(I work at Cloudflare and manage the Product Security team, so...disclaimer).

WAFs definitely help. No WAF is perfect, but having an additional layer to make exploitation harder, and having a tool designed to block specific attacks (like when a new CVE is issued for a CMS) is powerful.

Not to mention that WAFs are a requirement in regulated industries. PCI mandates it. And your SOC2 + ISO auditors probably will ask about it too.

[jcims]

For me the main benefit of a WAF is that ability to rapidly respond to zero day/CVE.

A good set of filters deters casual abusers and can amplify the signal from a skilled attack, but ultimately they tend to fail.

[tannhaeuser]

SQL injection can be as easy as accepting only quoted strings as parameters, with the parameter text not allowed to contain unescaped quotes itself, and converting strings to numbers and dates with SQL conversion funcs (wouldn't work with MySQL syntax though), or in fact using prepared statements. No need for heuristic best-efforts approaches.

[fivre]

having worked on, well, quite literally the other side of the room as the parent, i'll echo this and add a bit: WAFs are not perfect, WAFs are not themselves defense in depth, and WAFs are--most importantly--one facet in a complex set of tools that users find difficult to understand. Industry has perhaps come a long way in usable end-user browser security (hell yeah https://twitter.com/__apf__/), but it has a long way to go still end-user server security usability.

the major challenges i've seen with WAFs on that front are that users treat them (and often, any part of a security solution) as a panacea for general classes of problems, which they aren't. WAFs can provide excellent targeted defense ("this request looks like it's trying to exploit CVE-2020-4521 specifically, I should almost certainly block it") and very mediocre general defense ("this request kinda looks like it might be SQLi--block it?").

the latter suffers from the issues others have raised in adjacent comments: the WAF doesn't know if the defended application applies its own sanitization (it should, but for its function, the WAF assumes that upstream doesn't, and could be vulnerable) and/or if the request content is something that reasonably should include SQLi-like content. The Cloudflare WAF in particular, at least circa 2018, suffered from including a lot of OWASP project rules that could spot "naked" SQLi quite easily, but in doing so also triggered on a lot content where the appearance of SQLi was, in fact, normal usage of punctuation characters where they made sense in plain English prose--someone can and should legitimately use quotation marks in the course of writing a prose English comment, like I'm doing right now, along with an occasional semicolon or paren alongside quotes, because those same symbols have meaning and use in both SQL and English prose.

this leads to lots of fun user confusion scenarios, where someone on the sales side of thing says "yes! enable the WAF! more protection = more product value for you!", and some months after, someone on the support side says "sorry, but the WAF can also generate false positives on legit text content, or can miss legit malicious content if it's gift-wrapped effectively (a la the OP)".

that sort of nuance is really hard to understand for more naive users, who can't easily distinguish between "the WAF blocks things it can positively ID as threats", "the WAF blocks things it mistakenly identifies as a threat based on superficial similarity to actual threats", and "the WAF doesn't block things that are threats, but are crafted to avoid the WAF". Users just see ~WAF~, and unfortunately often see it as technological wizardry that does or should just work, because it's magic. It ain't, but communicating the nuances, to a general audience? That's damn hard, and has long been neglected across industry because it doesn't fit well into shiny marketing copy.

technical improvements are valuable, but they can only go so far--at some point, there's greater value in educational content that helps dispel the magic somewhat, so that users understand the shortcomings of any given tool and can spot when those shortcomings arise. Thankfully the whole Cloudflare TV project and other educational content does seem to be progressing, though im unfortunately too far removed from the day to day now to see how well it's succeeding :) optimism hat on, it is, and godspeed!

[beh9540]

I agree with you, in most cases, but unfortunately in some regulated industries, more and more auditors are putting WAFs as a requirement for secure architectures. No amount of explaining why it doesn't make sense changes anything, as the auditors rarely understand why they're asking for WAFs - they just need to check the box.

There are occasions though where WAFs can be somewhat useful, like where you need to secure a vendors webapp that you can't patch without them releasing a fix or trust, but for legacy or business reasons are required to run.

So some of us are forced to buy and implement these products regardless of effectiveness, and it is helpful to see how vendors respond I think.

[donmcronald]

I call this CYA (cover your ass) security. Passing blame for failures is more important than the technical merits of the product. If it fails you say "see ya" to the current vendor and hire a new whipping boy. Lol.

[itsdrewmiller]

“Not invulnerable” is not the same as snake oil. WAFs are a useful piece of a defense in depth strategy.

[girst]

Or they can lull you into a false sense of security. (which is the reason chrom{e,ium} has removed their XSS auditor)

[marcinzm]

>Or they can lull you into a false sense of security.

That applies to everything security related. "Don't review your source code for vulnerabilities, it may lull you into a false sense of security."

[itsdrewmiller]

That doesn’t seem to be true - googling says they removed it because it became too bad at doing its job and they didn’t want to maintain it.

https://www.google.com/amp/s/www.zdnet.com/google-amp/articl...

[icecap12]

As others have said, there are plenty of useful aspects to WAF technology. For my organization in particular, we have a lot of legacy junk floating around, and the WAF is an easy way to add a layer of protection to stuff nobody is working on anymore (keeping internet-facing systems up to date is another convo). As part of that legacy conversation, in addition to prevention of injection and other common web attacks, you get the added benefit of being able to add headers and upgrade TLS connections for old stuff to keep those pesky security scorecard reports off the CISOs desk. For most managed solutions, you can implement geo-blocking with a couple clicks. For the most part, a WAF is good for driveby stuff and zero-days. You have to look at it as just another part of a defense-in-depth strategy, and like any other control, if you put all your eggs in one basket it'll be a bad day. Definitely not snake-oil though.

[sk5t]

WAFs sound pretty darn good for simple, well-understood services with known good inputs. If every valid request to some half-forgotten Perl remnant in /cgi-bin looks like "path\?id=[0-9]{1,10}" then let that allow rule rip!

[ben509]

You have to understand the human element. In any big organization, you have many teams with varying security practices working on systems.

It's simply impossible to consistently recruit developers with good security knowledge, especially if we want, as an industry, to take responsibility for getting new developers up the first few rungs of the ladder.

And you do need a mechanism that can provide defense for legacy applications, or to quickly mitigate 0-days.

As long as we can't guarantee that developers won't screw up, we need tools for cyber-security to mitigate these attacks. WAFs and other layered security devices do fill that need.

However!

Any layered security device must be bypassable. Your WAF is probably configured by the same people who make the automated security tests your pen-testers run.

If your pen-testers aren't bypassing layered security and attacking your application directly, then you're not really doing layered security anymore. Your WAF's security becomes snake oil, and your application's security is untested.

[Spooky23]

That’s security hand wavy drama. By that standard why set a password, they are all crackable after all! The reality is that most attacks are automated kits or similar stuff that WAF combined with other controls can help with. It’s risk mitigation.

At the end of the day, the red team always wins. Tactical risk mitigation, segmentation and logging are the way to address security. Best case, your monitoring detects and alerts on the guy attacking the WAF, otherwise you have logs to conduct an investigation later.

[mhh__]

Wouldn't it be closer to something like Denuvo - the ambitious, skilled, people can get in but the script kiddies can't i.e. it buys you time

[dj_mc_merlin]

> (with enough time and determination)

Perfect, exactly what most people lack.

[tus88]

Well it depends, the WAF has multiple levels of strictness that will break origins if too strict. If an origin can tolerate the more strict levels, then it would be hard to bypass.