Live data from Hacker News

Writing "/etc/hosts" breaks the Substack editor

scalewithlee.substack.com

11–20 of 370 posts

Re: Writing "/etc/hosts" breaks the Substack editor

#11
post #4

This 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 a text string that is frequently associated with attacks and vulnerabilities. In general you want your WAF to block those things. This is indeed the point of a WAF. Except you also don't want it to get in the way of normal functionality (too much). That is what the security vs usability trade off is.

This particular rule is obviously off. I suspect it wasn't intended to apply to the POST payload of user content. Perhaps just URL parameters.

On a big enough website, users are doing weird stuff all the time and it can be tricky to write rules that stop the traffic you don't want while allowing every oddball legitimate request.

Re: Writing "/etc/hosts" breaks the Substack editor

#12
post #7

Does it block `/etc//hosts` or `/etc/./hosts`? This is a ridiculous kind of whack-a-mole that's doomed to failure. The people who wrote these should realize that hackers are smarter and more determined than they are and you should only rely on proven security, like not executing untrusted input.

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.

Re: Writing "/etc/hosts" breaks the Substack editor

#14
post #7

Does it block `/etc//hosts` or `/etc/./hosts`? This is a ridiculous kind of whack-a-mole that's doomed to failure. The people who wrote these should realize that hackers are smarter and more determined than they are and you should only rely on proven security, like not executing untrusted input.

Yeah, and this seems like a common Fortune 500 mandatory checkbox. Gotta have a Web Application Firewall! Doesn't matter what the rules are, as long as there are a few. Once I was told I needed one to prevent SQL injection attacks... against an application that didn't use an SQL database.

If you push back you'll always get a lecture on "defense in depth", and then they really look at you like you're crazy when you suggest that it's more effective to get up, tap your desk once, and spin around in a circle three times every Thursday morning. I don't know... I do this every Thursday and I've never been hacked. Defense in depth, right? It can't hurt...

Re: Writing "/etc/hosts" breaks the Substack editor

#16
post #7

Does it block `/etc//hosts` or `/etc/./hosts`? This is a ridiculous kind of whack-a-mole that's doomed to failure. The people who wrote these should realize that hackers are smarter and more determined than they are and you should only rely on proven security, like not executing untrusted input.

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" ?

Re: Writing "/etc/hosts" breaks the Substack editor

#17
post #4

This 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.

> is run by people who have no idea how text input works

That's a very uncharitable view. It's far more likely that they are simply using some WAF with sane defaults and never caught this. They'll fix it and move on.

Re: Writing "/etc/hosts" breaks the Substack editor

#19
Reminds 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...

Re: Writing "/etc/hosts" breaks the Substack editor

#20
post #9

[flagged]

You figured all that out just because the headers indicate the site passed through Cloudflare at one point? That's quite a leap!

If Cloudflare had a default rule that made it impossible to write that string on any site with their WAF, wouldn't this be a lot more widespread? Much more likely someone entered a bad rule into Cloudflare, or Cloudflare isn't involved in that rule at all.

Post reply on HN