|
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! |