←back to thread

Writing "/etc/hosts" breaks the Substack editor

(scalewithlee.substack.com)
601 points scalewithlee | 7 comments | 25 Apr 25 13:48 UTC | HN request time: 0.25s | source | bottom
Show context
matt_heimer ◴[25 Apr 25 14:33 UTC] 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 #
1. krferriter ◴[25 Apr 25 15:09 UTC] 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 #
2. ordersofmag ◴[25 Apr 25 16:35 UTC] No.43795646[source]▶
A simple reason would be if you're just using it as a proxy signal for bad bots and you want to reduce the load on your real servers and let them get rejected at the CDN level. Obvious SQL injection attempt = must be malicious bot = I don't want my servers wasting their time
3. immibis ◴[25 Apr 25 17:42 UTC] 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 #
4. pxc ◴[25 Apr 25 18:45 UTC] No.43797203[source]▶
WAFs can be a useful site of intervention during incidents or when high-severity vulns are first made public. It's not a replacement for fixing the vuln, that still has to happen, but it gives you a place to mitigate it that may be faster or simpler than deploying code changes.
5. nijave ◴[25 Apr 25 19:43 UTC] No.43797818[source]▶
The farther a request makes it into infrastructure, the more resources it uses.
6. gopher_space ◴[25 Apr 25 21:28 UTC] 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.
7. benregenspan ◴[26 Apr 25 02:37 UTC] No.43800431[source]▶
It should be thought of as defense-in-depth only. The backend had better be immune to SQL injection, but what if someone (whether in-house or vendor) messes that up?

I do wish it were possible to write the rules in a more context-sensitive way, maybe possible with some standards around payloads (if the WAF knows that an endpoint is accepting a specific structured format, and how escapes work in that format, it could relax accordingly). But that's probably a pipe dream. Since the backend could be doing anything, paranoid rulesets have to treat even escaped data as a potential issue and it's up to users to poke holes.