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

81–90 of 370 posts

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

#81

Post by krferriter »

CoffeeOnWrite wrote: post #49
bombcar wrote: post #21

Earlier quoted context omitted.

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.

Denial of service prevention and throttling of heavy users is a fine use, searching for a list of certain byte strings inside input fields and denying requests that contain them isn't.

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

#82

Post by wyager »

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.

Why? It obviously has an annoying cost and equally obviously won't stop any hacker with a lukewarm IQ

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

#83

Post by augusto-moura »

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.

How would that be hard? Getting the absolute path of a string is in almost all languages stdlibs[1]. You can just grep for any string containing slashes and try resolve them and voilá

Resolving wildcards is trickier but definitely possible if you have a list of forbidden files

[1]: https://nodejs.org/api/path.html#pathresolvepaths

Edit: changed link because C's realpath has a slightly different behavior

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

#84

Post by lucianbr »

mjr00 wrote: post #65
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 disagree with other posts here, it is partially a balance between security and usability. And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in th…

There should be some limits and some consequences to the insurer as well. I don't think the insurer is god and should be able to request anything no matter if it makes sense or not and have people and companies comply.

If anything, I think this attitude is part of the problem. Management, IT security, insurers, governing bodies, they all just impose rules with (sometimes, too often) zero regard for consequences to anyone else. If no pushback mechanism exists against insurer requirements, something is broken.

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

#85

Post by josephcsible »

mjr00 wrote: post #65
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 disagree with other posts here, it is partially a balance between security and usability. And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in th…

Why wouldn't the IT people just tell the grumbling employees that exact explanation?

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

#86

Post by blenderob »

> This case highlights an interesting tension in web security: the balance between protection and usability.

But it doesn't. This case highlights a bug, a stupid bug. This case highlights that people who should know better, don't!

The tension between security and usability is real but this is not it. Tension between security and usability is usually a tradeoff. When you implement good security that inconveniences the user. From simple things like 2FA to locking out the user after 3 failed attempts. Rate limiting to prevent DoS. It's a tradeoff. You increase security to degrade user experience. Or you decrease security to increase user experience.

This is neither. This is both bad security and bad user experience. What's the tension?

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

#87

Post by stingraycharles »

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…

Yup. Were a database company that needs to be compliant with SOC2, and I’ve had extremely long and tiring arguments with our auditor why we couldn’t adhere to some of these standard WAF rulesets because it broke our site (we allow people to spin up a demo env and trigger queries).

We changed auditors after that.

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

#88

Post by pyrale »

smallnix wrote: post #30
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.

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

Dropping 95% is even more secure, plus it lives the lucky few that get past it a sense of pride and exclusivity.

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

#89

Post by mrspuratic »

Null-Set wrote: post #69

This looks like it was caused by this update https://developers.cloudflare.com/waf/change-log/2025-04-22/ rule 100741. It references this CVE https://github.com/tuo4n8/CVE-2023-22047 which allows the reading of system files. The example given shows them reading /etc/passwd

AFAICT it's also (though I'm very rusty) in ModSecurity, if XML content processing is enabled then rules like these will trip:

    SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@pmFromFile lfi-os-files.data"
    SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@pmFromFile unix-shell.data" ...
where the referenced files contain the usual list of *nix suspects including the offending filename (lfi-os-files.data, "local file inclusion" attacks)

The advantage (whack-a-mole notwithstanding) of a WAF is it orders of magnitude easier to tweak WAF rules than upgrade say, Weblogic, or other teetering piles of middleware.

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

#90

Post by mjr00 »

swiftcoder wrote: post #78
mjr00 wrote: post #65

Earlier quoted context omitted.

> I disagree with other posts here, it is partially a balance between security and usability. And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in th…

Not just economics, audit processes also really encourage adopting large rulesets wholesale. We're SOC2 + HIPAA compliant, which either means convincing the auditor that our in-house security rules cover 100% of the cases they care about... or we buy an off-the-shelf WAF that has already completed the compliance process, and call it a day. The CTO is going to pick the second option every time.

Yeah. SOC2 reminds me that I didn't mention sales as well, another security-as-economics feature. I've seen a lot of enterprise RFPs that mandate certain security protocols, some of which are perfectly sensible and others... not so much. Usually this is less problematic than insurance because the buyer is more flexible, but sometimes they (specifically, the buyer's company's security team, who has no interest besides covering their own ass) refuse to budge.

If your startup is on the verge of getting a 6 figure MRR deal with a company, but the company's security team mandates you put in a WAF to "protect their data"... guess you're putting in a WAF, like it or not.

Post reply on HN