Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing "/etc/hosts" breaks the Substack editor

scalewithlee.substack.com

Post reply on HN
Print view View original

21–30 of 370 posts

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

#21

Post by bombcar »

jrockway wrote: post #14
Y_Y wrote: 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 su…

I love that having a web application firewall set to allow EVERYTHING passes the checkbox requirement ...

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

#22

Post by pimanrules »

We faced a similar issue in our application. Our internal Red Team was publishing data with XSS and other injection attack attempts. The attacks themselves didn't work, but the presence of these entries caused our internal admin page to stop loading because our corporate firewall was blocking the network requests with those payloads in them. So an unsuccessful XSS attack became an effective DoS attack instead.

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

#23

Post by 0xbadcafebee »

Worth noting that people here are assuming that the author's assumption is correct, that his writing /etc/hosts is causing the 403, and that this is either a consequence of security filtering, or that this combination of characters at all that's causing the failure. The only evidence he has, is he gets back a 403 forbidden to an API request when he writes certain content. There's a thousand different things that could be triggering that 403.

It's not likely to be a WAF or content scanner, because the HTTP request is using PUT (which browser forms don't use) and it's uploading the content as a JSON content-type in a JSON document. The WAF would have to specifically look for PUTs, open up the JSON document, parse it, find the sub-string in a valid string, and reject it. OR it would have to filter raw characters regardless of the HTTP operation.

Neither of those seem likely. WAFs are designed to filter on specific kinds of requests, content, and methods. A valid string in a valid JSON document uploaded by JavaScript using a JSON content-type is not an attack vector. And this problem is definitely not path traversal protection, because that is only triggered when the string is in the URL, not some random part of the content body.

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

#24

Post by arp242 »

Few 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 hot take and say that WAFs are bollocks mainly used by garbage software. I'm not saying a good developer can't make a mistake and write a path traversal, but if you're really worried about that then there are better ways to prevent that than this approach which obviously is going to negatively impact users in weird and mysterious ways. It's like the naïve /(fuck|shit|...)/g-type "bad word filter". It shows a fundamental lack of care and/or competency.

Aside: is anyone still storing passwords in /etc/passwd? Storing the password in a different root-only file (/etc/shadow, /etc/master.passwd, etc.) has been a thing on every major system since the 90s AFAIK?

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

#26

Post by mystifyingpoi »

paxys wrote: post #16
mystifyingpoi wrote: post #12

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

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.

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

#27

Post by [deleted] »

paxys wrote: post #16
mystifyingpoi wrote: post #12

Earlier 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

#28

Post by eli »

Y_Y wrote: 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.

Is a security solution worthless if it can't stop a dedicated attacker? A lot of WAF rules are blocking probes from off-the-shelf vulnerability scanners.

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

#30

Post by smallnix »

mystifyingpoi wrote: post #12
Y_Y wrote: 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.

Dropping 0.5% of requests will prevent even the most sophisticated attacks (think APT!). Sometimes.
Post reply on HN