←back to thread

603 points scalewithlee | 1 comments | | HN request time: 0.241s | 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(14): >>43794129 #>>43794136 #>>43794174 #>>43794203 #>>43794226 #>>43794234 #>>43794368 #>>43794502 #>>43795948 #>>43796540 #>>43798420 #>>43800243 #>>43804110 #>>43805902 #
krferriter ◴[] No.43794368[source]
I don't get why you'd have SQL injection filtering of input fields at the CDN level. Or any validation of input fields aside from length or maybe some simple type validation (number, date, etc). Your backend should be able to handle arbitrary byte content in input fields. Your backend shouldn't be vulnerable to SQL injection if not for a CDN layer that's doing pre-filtering.
replies(4): >>43795646 #>>43796489 #>>43797818 #>>43800431 #
immibis ◴[] No.43796489[source]
Because someone said "we need security" and someone else said "what is security" and someone else said "SQL injection is security" and someone looked up SQL injections and saw the word "select" and "insert".

WAFs are always a bad idea (possible exception: in allow-but-audit mode). If you knew the vulnerabilities you'd protect against them in your application. If you don't know the vulnerabilities all you get is a fuzzy feeling that Someone Else is Taking Care of it, meanwhile the vulnerabilities are still there.

Maybe that's what companies pay for? The feeling?

replies(2): >>43797203 #>>43798702 #
1. gopher_space ◴[] No.43798702[source]
If your clients will let you pass the buck on security like this it would be very tempting to work towards the least onerous insurance metric and no further.