←back to thread

600 points scalewithlee | 3 comments | | HN request time: 0s | source
Show context
matt_heimer ◴[] No.43794013[source]
The people configuring WAF rules at CDNs tend to do a poor job understanding sites and services that discuss technical content. It's not just Cloudflare, Akamai has the same problem.

If your site discusses databases then turning on the default SQL injection attack prevention rules will break your site. And there is another ruleset for file inclusion where things like /etc/hosts and /etc/passwd get blocked.

I disagree with other posts here, it is partially a balance between security and usability. You never know what service was implemented with possible security exploits and being able to throw every WAF rule on top of your service does keep it more secure. Its just that those same rulesets are super annoying when you have a securely implemented service which needs to discuss technical concepts.

Fine tuning the rules is time consuming. You often have to just completely turn off the ruleset because when you try to keep the ruleset on and allow the use-case there are a ton of changes you need to get implemented (if its even possible). Page won't load because /etc/hosts was in a query param? Okay, now that you've fixed that, all the XHR included resources won't load because /etc/hosts is included in the referrer. Now that that's fixed things still won't work because some random JS analytics lib put the URL visited in a cookie, etc, etc... There is a temptation to just turn the rules off.

replies(13): >>43794129 #>>43794136 #>>43794174 #>>43794203 #>>43794226 #>>43794234 #>>43794368 #>>43794502 #>>43795948 #>>43796540 #>>43798420 #>>43800243 #>>43804110 #
gfiorav ◴[] No.43794136[source]
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.

replies(3): >>43794334 #>>43794402 #>>43795672 #
wat10000 ◴[] No.43795672[source]
Sorry, we have to reject your comment due to security. The text "Cloudflare<apostrophe>s" is a potential SQL injection.
replies(1): >>43796551 #
1. gfiorav ◴[] No.43796551{3}[source]
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.

replies(2): >>43796953 #>>43802532 #
2. wat10000 ◴[] No.43796953[source]
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.
3. int_19h ◴[] No.43802532[source]
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.