3 ms·

I agree. From a product perspective, I would also support the decision. Should we make the rules more complex by default, potentially overlooking SQL injection

I agree. From a product perspective, I would also support the decision. Should we make the rules more complex by default, potentially overlooking SQL injection vulnerabilities? Or should we blanket prohibit anything that even remotely resembles SQL, allowing those edge cases to figure it out? I favor the latter approach. That group of Cloudflare users will understand the complexity of their use case accepting SQL in payloads and will be well-positioned to modify the default rules. They will know exactly where they want to allow SQL usage. From Cloudflare’s perspective, it is virtually impossible to reliably cover every conceivable valid use of SQL, and it is likely 99% of websites won’t host SQL content.

Y_Y 1y ago
Why not just whitelist the thousand most common words? That should be good enough for 99% of approriate content, and the smelly nerds who make websites or talk about them can take their tiny market segment and get bent.
krferriter 1y 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.
- p_ing 1y ago
  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.
  - krferriter 1y ago
    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.
    - p_ing 1y ago
      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.
  - RKFADU_UOFCCLEL 1y ago
    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.
    - p_ing 1y ago
      That's a very narrow view of what a WAF does. You may want to review the OWASP ruleset at https://coreruleset.org/ 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.
      - TheDong 1y ago
        Okay, I'll look at the "coreruleset" which you say is good. Let's see what's blocked: "Division by zero" anywhere in the response body since that's a php error. Good luck talking about math ([0] and [1]) Common substrings in webshells, all matched as strings in response bodies, rather than parsing HTML, so whatever, don't comment about webshells either [2] Unless the body is compressed, in which case don't apply the above. Security [3]. Also, read this regex and tell me you understand what it's doing. Tell me the author of it understands what it matches: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf#L231 https://github.com/coreruleset/coreruleset/blob/943a6216edea... What the coreruleset is doing here is trying to parse HTML, SQL, HTTP, and various other languages with Regular Expressions. This doesn't work. This will never give you a right result. It's trying to keep up to date with the string representation of java and php errors, without even knowing the version of Java the server is running, and without the Java maintainers, who constantly add new errors, having any say. The only reasons attackers aren't evading the webshell rules here trivially is because so few people use these rules in practice that they're not even worth defeating (and it is quite easy to have your php webshell generate unique html each load, which cannot be matched by a regular expression short of /.*/; html is not a regular grammar). I was ready to see something that made WAFs feel like they did _anything_ based on your comment, but all I see is a pile of crap that I would not want anywhere near my site. Filtering java error strings and php error strings out of my rust app's responses using regexes to parse html is just such a clown-world idea of security. Blocking the loading of web-shells until the attacker changes a single character in the 'title' block of the output html seems so dumb when my real problem is that someone could write an arbitrary executable to my server. Every WAF ruleset I've read so far has made me sure it's a huge pile of snake-oil, and this one is no different. [0]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/php-errors.data#L265 https://github.com/coreruleset/coreruleset/blob/943a6216edea... [1]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf#L35 https://github.com/coreruleset/coreruleset/blob/943a6216edea... [2]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/web-shells-php.data#L143 https://github.com/coreruleset/coreruleset/blob/943a6216edea... [3]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/RESPONSE-955-WEB-SHELLS.conf#L15-L16 https://github.com/coreruleset/coreruleset/blob/943a6216edea...
  - immibis 1y ago
    My defense in depth blocks Content-Length that's a prime number or divisible by 5. Can't be too safe!
wat10000 1y ago
Sorry, we have to reject your comment due to security. The text "Cloudflare<apostrophe>s" is a potential SQL injection.
- gfiorav 1y ago
  You know, I get the spirit of this criticism. But, specially in the age of AI, we're going to get thousands of barely reviewed websites on Cloudflare. If you know what you're doing, turn these protections off. If you don't, there's one less hole out there.
  - wat10000 1y ago
    In all seriousness, I don't see the justification for blocking "/etc/hosts" but allowing "'". The latter is probably a million times more likely to trigger a vulnerability.
  - int_19h 1y ago
    The problem is that people who don't know what they are doing join the cargo cult and then impose these requirements on people who do know what they are doing.

Y_Y 1y ago

Why not just whitelist the thousand most common words? That should be good enough for 99% of approriate content, and the smelly nerds who make websites or talk about them can take their tiny market segment and get bent.

krferriter 1y 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.

p_ing 1y ago
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.
- krferriter 1y ago
  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.
  - p_ing 1y ago
    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.
- RKFADU_UOFCCLEL 1y ago
  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.
  - p_ing 1y ago
    That's a very narrow view of what a WAF does. You may want to review the OWASP ruleset at https://coreruleset.org/ 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.
    - TheDong 1y ago
      Okay, I'll look at the "coreruleset" which you say is good. Let's see what's blocked: "Division by zero" anywhere in the response body since that's a php error. Good luck talking about math ([0] and [1]) Common substrings in webshells, all matched as strings in response bodies, rather than parsing HTML, so whatever, don't comment about webshells either [2] Unless the body is compressed, in which case don't apply the above. Security [3]. Also, read this regex and tell me you understand what it's doing. Tell me the author of it understands what it matches: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf#L231 https://github.com/coreruleset/coreruleset/blob/943a6216edea... What the coreruleset is doing here is trying to parse HTML, SQL, HTTP, and various other languages with Regular Expressions. This doesn't work. This will never give you a right result. It's trying to keep up to date with the string representation of java and php errors, without even knowing the version of Java the server is running, and without the Java maintainers, who constantly add new errors, having any say. The only reasons attackers aren't evading the webshell rules here trivially is because so few people use these rules in practice that they're not even worth defeating (and it is quite easy to have your php webshell generate unique html each load, which cannot be matched by a regular expression short of /.*/; html is not a regular grammar). I was ready to see something that made WAFs feel like they did _anything_ based on your comment, but all I see is a pile of crap that I would not want anywhere near my site. Filtering java error strings and php error strings out of my rust app's responses using regexes to parse html is just such a clown-world idea of security. Blocking the loading of web-shells until the attacker changes a single character in the 'title' block of the output html seems so dumb when my real problem is that someone could write an arbitrary executable to my server. Every WAF ruleset I've read so far has made me sure it's a huge pile of snake-oil, and this one is no different. [0]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/php-errors.data#L265 https://github.com/coreruleset/coreruleset/blob/943a6216edea... [1]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf#L35 https://github.com/coreruleset/coreruleset/blob/943a6216edea... [2]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/web-shells-php.data#L143 https://github.com/coreruleset/coreruleset/blob/943a6216edea... [3]: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/RESPONSE-955-WEB-SHELLS.conf#L15-L16 https://github.com/coreruleset/coreruleset/blob/943a6216edea...
- immibis 1y ago
  My defense in depth blocks Content-Length that's a prime number or divisible by 5. Can't be too safe!

wat10000 1y ago

Sorry, we have to reject your comment due to security. The text "Cloudflare<apostrophe>s" is a potential SQL injection.

gfiorav 1y ago
You know, I get the spirit of this criticism. But, specially in the age of AI, we're going to get thousands of barely reviewed websites on Cloudflare. If you know what you're doing, turn these protections off. If you don't, there's one less hole out there.
- wat10000 1y ago
  In all seriousness, I don't see the justification for blocking "/etc/hosts" but allowing "'". The latter is probably a million times more likely to trigger a vulnerability.
- int_19h 1y ago
  The problem is that people who don't know what they are doing join the cargo cult and then impose these requirements on people who do know what they are doing.