Similar:
Writing `find` as the first word in your search will prevent Firefox from accepting the “return” key is pressed.
Pretty annoying.
Writing "/etc/hosts" breaks the Substack editor
31–40 of 370 posts
Re: Writing "/etc/hosts" breaks the Substack editor
#32Reminds me of an anecdote about an e-commerce platform: someone coded a leaky webshop, so their workaround was to watch if the string "OutOfMemoryException" shows up in the logs, and then restart the app. Another developer in the team decided they wanted to log what customers searched for, so if someone typed in "OutOfMemoryException" in the search bar...
I've actually gone through this a few times with our WAF. A user got IP-banned because the WAF thought a note with the string "system(..." was PHP injection.
Re: Writing "/etc/hosts" breaks the Substack editor
#33Earlier quoted context omitted.
> But having it is generally better than not having it. So is HN and every other site in the world insecure because it allows users to post "/etc/hosts" ?
Maybe? I don't know nor care. Assuming that HN has a vuln with path traversal, a sanely configured WAF would block the traversal attempt.
*some traversal attempts
Re: Writing "/etc/hosts" breaks the Substack editor
#34I ran into a similar issue with OpenRouter last night. OpenRouter is a “switchboard” style service that provides a single endpoint from which you can use many different LLMs. It’s great, but last night I started to try using it to see what models are good at processing raw HTML in various ways. It turns out OpenRouter’s API is protected by Cloudflare and something about specific raw chunks of HTML and JavaScript in t…
Did you report it?
Re: Writing "/etc/hosts" breaks the Substack editor
#35Earlier quoted context omitted.
No one expects any WAF to be a 100% solution that catches all exfiltration attempts ever, and it should not be treated this way. But having it is generally better than not having it.
> But having it is generally better than not having it. So is HN and every other site in the world insecure because it allows users to post "/etc/hosts" ?
[deleted]
Re: Writing "/etc/hosts" breaks the Substack editor
#36The 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.
Re: Writing "/etc/hosts" breaks the Substack editor
#37[flagged]
[deleted]
Re: Writing "/etc/hosts" breaks the Substack editor
#38Few years ago I had an application that allowed me to set any password, but then gave mysterious errors when I tried to use that password to login. Took me a bit to figure out what was going on, but their WAF blocked my "hacking attempt" of using a ' in the password. The same application also stored my full password in localStorage and a cookie (without httponly or secure). Because reasons. Sigh. I'm going to do a ho…
It's more that /etc/hosts and /etc/passwd are good for testing because they always exist with predictable contents on almost every system. If you inject "cat /etc/passwd" to various URLs you can grep for "root:" to see if it worked.
So it's really blocking doorknob-twisting scripts.
Re: Writing "/etc/hosts" breaks the Substack editor
#39This isn't a "security vs usability" trade-off as the author implies. This has nothing to do with security at all. /etc/hosts See, HN didn't complain. Does this mean I have hacked into the site? No, Substack (or Cloudflare, wherever the problem is) is run by people who have no idea how text input works.
It's more so that Cloudflare has a WAF product that checks a box for security and makes people who's job it is to care about boxes being checked happy.
For example, I worked with a client that had a test suite of about 7000 or so strings that should return a 500 error, including /etc/hosts and other ones such as:
../../apache/logs/error.log
AND%20(SELECT%208203%20FROM%20(SELECT(SLEEP(5)))xGId)
/../..//../..//../..//../winnt/system32/netstat.exe?-a
We ended up deploying a WAF to block all these requests, even though it didn't improve security in any meaningful way.