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

51–60 of 370 posts

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

#51

Post by _blk »

matt_heimer wrote: post #36

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…

100! [good] security just doesn't work as a mixing pattern... I'm not saying it's necessarily bad to use those additional protections but they come with severe limitations so the total value (as in cost/benefit) is hard to gauge.

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

#52

Post by ryandrake »

0xbadcafebee wrote: post #23

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…

If you change a single string in the HTTP payload and it works, what other explanation makes sense besides a text scanner somewhere along the path to deploying the content?

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

#53

Post by latexr »

mystifyingpoi wrote: post #26
paxys wrote: post #16

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

I propose someone who doesn’t know or care how a system works shouldn’t be prescribing what to do to make it secure. Otherwise this is like suggesting every gate must have a lock to be secure, even those which aren’t connected to any walls.

https://i.imgur.com/ntYUQB1.jpeg

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

#54

Post by gfiorav »

matt_heimer wrote: post #36

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…

I agree. From a product perspective, I would also support the decision. Should we make the rules more complex by default, potentially overlooking SQL injection vulnerabilities? Or should we blanket prohibit anything that even remotely resembles SQL, allowing those edge cases to figure it out?

I favor the latter approach. That group of Cloudflare users will understand the complexity of their use case accepting SQL in payloads and will be well-positioned to modify the default rules. They will know exactly where they want to allow SQL usage.

From Cloudflare’s perspective, it is virtually impossible to reliably cover every conceivable valid use of SQL, and it is likely 99% of websites won’t host SQL content.

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

#55

Post by simonw »

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.

"But having it is generally better than not having it."

I believe the exact opposite.

One (of many) reasons is that it can make your code less secure, by hiding your security mistakes from you.

If your WAF obscures escaping issues during your own testing and usage you could very easily let those escaping issues go unresolved - leaving you vulnerable to any creative attacker who can outsmart your WAF.

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

#57

Post by simonw »

apetresc wrote: post #47
0xbadcafebee wrote: post #23

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

Yeah, the author clearly put the work in to demonstrate what's happening here.

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

#58

Post by simonw »

SonOfLilit wrote: post #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 fi…

Do you remember if that was Cloudflare or some other likely WAF?

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

#59

Post by teddyh »

> For now, I'll continue using workarounds like "/etc/h*sts" (with quotes) or alternative spellings when discussing system paths in my Substack posts.

Ahh, the modern trend of ”unalived”¹ etc. comes to every corner of society eventually.

1. https://knowyourmeme.com/memes/unalive>

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

#60

Post by ryandrake »

matt_heimer wrote: post #36

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…

This looks like a variation of the Scunthorpe problem[1], where a filter is applied too naively, aggressively, and in this case, to the wrong content altogether. Applying the filter to "other stuff" sent to and among the servers might make sense, but there doesn't seem to be any security benefit to filtering actual text payload that's only going to be displayed as blog content. This seems like a pretty cut and dried bug to me.

1: https://en.wikipedia.org/wiki/Scunthorpe_problem

Post reply on HN