Comment by krferriter
1 day ago
If your web application is relying on Cloudflare filtration of input values to prevent SQL injection, your web application is vulnerable to SQL injection.
1 day ago
If your web application is relying on Cloudflare filtration of input values to prevent SQL injection, your web application is vulnerable to SQL injection.
Defense in-depth. I would hope few would want a vulnerable web app and simply protect it via a WAF. But just because your web app is 'invulnerable' doesn't mean you should forgo the WAF.
But what is being defended against? This is blocking legitimate user behavior. Would it be defense in depth to also prohibit semicolons or two consecutive hyphen characters in all content? If your app is constructing paths to read from the server's filesystem based on substrings contained within client-provided field values, throwing an error if `"/etc/hosts"` appears in any input is not going to save you.
Unknown or unforeseen attacks. The WAF ruleset can be updated much faster than code. WAFs also provide flexibility in how requests are responded to, or even disallow access from IP ranges, certain browsers, etc.
WAFs do throw false positives and do require adjustments OOTB for most sites, but you’re missing the forest by focusing on this single case.
My defense in depth blocks Content-Length that's a prime number or divisible by 5. Can't be too safe!
What? If I construct my queries the right way (e.g., not concatenating strings together like it's the year 1990), then I never will want a WAF "helping" me by blocking my users because they have an apostrophe in their name.
That's a very narrow view of what a WAF does. You may want to review the OWASP ruleset at https://coreruleset.org/. However, this is just the ruleset. WAF vendors usually offer features above and beyond OWASP rule parsing.
And WAF rules can be tuned. There's no reason an apostrophe in a username or similar needs to be blocked, if it were by a rule.
2 replies →