←back to thread

Writing "/etc/hosts" breaks the Substack editor

(scalewithlee.substack.com)
600 points scalewithlee | 3 comments | 25 Apr 25 13:48 UTC | HN request time: 0s | source
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(13): >>43794129 #>>43794136 #>>43794174 #>>43794203 #>>43794226 #>>43794234 #>>43794368 #>>43794502 #>>43795948 #>>43796540 #>>43798420 #>>43800243 #>>43804110 #
mjr00 ◴[25 Apr 25 14:55 UTC] No.43794226[source]▶
> I disagree with other posts here, it is partially a balance between security and usability.

And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in the face that it's bad practice, NIST changed its policy to recommend not regularly rotating passwords over a decade ago, etc., and be totally correct... but they're still going to jack up premiums if you don't do it. So you dejectedly sigh, implement a password expiration policy, and listen to grumbling employees who call you incompetent.

It's been a while since I've been through a process like this, but given how infamous log4shell became, it wouldn't surprise me if insurers are now also making it mandatory that common "hacking strings" like /etc/hosts, /etc/passwd, jndi:, and friends must be rejected by servers.

replies(12): >>43794339 #>>43794401 #>>43794476 #>>43794485 #>>43794676 #>>43794868 #>>43795485 #>>43797735 #>>43799077 #>>43799776 #>>43800796 #>>43802890 #
1. II2II ◴[25 Apr 25 22:29 UTC] No.43799077[source]▶
> If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in the face that it's bad practice, NIST changed its policy to recommend not regularly rotating passwords over a decade ago, etc., and be totally correct... but they're still going to jack up premiums if you don't do it.

I would argue that password policies are very context dependent. As much as I detest changing my password every 90 days, I've worked in places where the culture encouraged password sharing. That sharing creates a whole slew of problems. On top of that, removing the requirement to change passwords every 90 days would encourage very few people to select secure passwords, mostly because they prefer convenience and do not understand the risks.

If you are dealing with an externally facing service where people are willing to choose secure passwords and unwilling to share them, I would agree that regularly changing passwords creates more problems than it solves.

replies(1): >>43799353 #
2. Aeolun ◴[25 Apr 25 23:13 UTC] No.43799353[source]▶
> removing the requirement to change passwords every 90 days would encourage very few people to select secure passwords

When you don’t require them to change it, you can just assign them a random 16 character string and tell them it’s their job to memorize it.

replies(1): >>43802865 #
3. phito ◴[26 Apr 25 12:05 UTC] No.43802865[source]▶
There's no way I will ever remember it. I will write it down. Let me choose my own password (passphrase if I need to remember it)