Live data from Hacker News

Writing "/etc/hosts" breaks the Substack editor

scalewithlee.substack.com

41–50 of 370 posts

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

#41
post #9

[flagged]

I think Cloudflare WAF is a good product compared to other WAFs - by definition a WAF is intended to layer on validation that properly built applications should be doing, so it's sort of expected that it would reject valid potentially harmful content.

I think you can fairly criticise WAF products and the people who advocate for them (and created the need for them) but I don't think the CF team responsible can really be singled out.

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

#42

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.

This is funny and sad at the same time.

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

#43
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.

See "enumerating badness" as a losing strategy. I knew this was a bad idea about 5 minutes after starting my first job in 1995.

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

#44
I encountered this a while ago and it was incredibly frustrating. The "Network error" prevented me from updating a post I had written for months because I couldn't figure out why my edits (which extended the length and which I assumed was the problem) couldn't get through.

Trying to contact support was difficult too due to AI chatbots, but when I finally did reach a human, their "tech support" obviously didn't bother to look at this in any reasonable timeframe.

It wasn't until some random person on Twitter suggested the possibility of some magic string tripping over some stupid security logic that I found the problem and could finally edit my post.

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

#45
post #10

It's something I ran into quite a few times in my career. It's a weird call to get if the client can't save their cms site, due to typing something harmless. I think worst was when there was a dropdown that I defined which had a value in the mod rules that was not allowed.

I cannot reproduce this.

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

#46
After having been bitten once (was teaching a competitive programming team, half the class got a blank page when submitting solutions, after an hour of debugging I narrowed it down to a few C++ types and keywords that cause 403 if they appear in the code, all of which happen to have meaning in Javascript), and again (working for a bank, we had an API that you're supposed to submit a python file to, and most python files would result in 403 but short ones wouldn't... a few hours of debugging and I narrowed it down to a keyword that sometimes appears in the code) and then again a few months later (same thing, new cloud environment, few hours burned on debugging[1]), I had the solution to his problem in mind _immediately_ when I saw the words "network error".

[1] the second time it happened, a colleague added "if we got 403, print "HAHAHA YOU'VE BEEN WAFFED" to our deployment script, and for that I am forever thankful because I saw that error more times than I expected

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

#47

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 coul…

It sure looks like the author did his due diligence; he has a chart of all the different phrases in the payload which triggered the 403 and they all corresponded to paths to common UNIX system configuration files.

Nobody could prove that's exactly what's happening without seeing Cloudflare's internal WAF rules, but can you think of any other reasonable explanation? The endpoint is rejecting a PUT who's payload contains exactly /etc/hosts, /etc/passwd, or /etc/ssh/sshd_config, but NOT /etc/password, /etc/ssh, or /etc/h0sts. What else could it be?

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

#48
post #28
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.

"It's technically better than nothing," is kind of a bizarre metric.

It's like not allowing the filesystem to use the word "virus" in a file name. Yes, it technically protects against some viruses, but it's really not very difficult to avoid while being a significant problem to a fair number of users with a legitimate use case.

It's not that it's useless. It's that it's stupid.

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

#49
post #21

Earlier quoted context omitted.

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

(I’m in the anti-WAF camp) That does stand to improve your posture by giving you the ability to quickly apply duct tape to mitigate an active mild denial of service attack. It’s not utterly useless.

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

#50
"How could Substack improve this situation for technical writers?"

How about this: don't run a dumb as rocks Web Application Firewall on an endpoint where people are editing articles that could be about any topic, including discussing the kind of strings that might trigger a dumb as rocks WAF.

This is like when forums about web development implement XSS filters that prevent their members from talking about XSS!

Learn to escape content properly instead.

Post reply on HN