Writing "/etc/hosts" breaks the Substack editor • Hacker News Board

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

#71

Post by Y_Y » Fri, Apr 25, 2025, 3:06 PM UTC

gfiorav wrote: post #54

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…

Why not just whitelist the thousand most common words? That should be good enough for 99% of approriate content, and the smelly nerds who make websites or talk about them can take their tiny market segment and get bent.

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

#72

Post by Wowfunhappy » Fri, Apr 25, 2025, 3:07 PM UTC

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…

Maybe it wouldn't make a difference, but if I was the IT person telling users they have to change their passwords every 90 days, I would 100% include a line in the email blaming the insurance company.

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

#73

Post by thunderfork » Fri, Apr 25, 2025, 3:07 PM UTC

elevation wrote: post #62

CoffeeOnWrite wrote: post #49

Earlier quoted context omitted.

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

Doesn't it also add latency to every request?

[dead]

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

#74

Post by ndsipa_pomu » Fri, Apr 25, 2025, 3:08 PM UTC

eli wrote: post #28

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.

It's merely security theater.

It reminds me of when airports started scanning people's shoes because an attacker had used a shoe bomb. Yes, that'll stop an attacker trying a shoe bomb again, but it disadvantages every traveller and attackers know to put explosives elsewhere.

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

#75

Post by kmoser » Fri, Apr 25, 2025, 3:09 PM UTC

apetresc wrote: post #56

righthand wrote: post #31

Similar: Writing `find` as the first word in your search will prevent Firefox from accepting the “return” key is pressed. Pretty annoying.

I can't reproduce this; is it still the case, or some ancient thing?

I can't reproduce it, either, using FF 137.0.2 (64-bit) on Windows.

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

#76

Post by krferriter » Fri, Apr 25, 2025, 3:09 PM UTC

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 don't get why you'd have SQL injection filtering of input fields at the CDN level. Or any validation of input fields aside from length or maybe some simple type validation (number, date, etc). Your backend should be able to handle arbitrary byte content in input fields. Your backend shouldn't be vulnerable to SQL injection if not for a CDN layer that's doing pre-filtering.

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

#77

Post by reaperducer » Fri, Apr 25, 2025, 3:10 PM UTC

chii wrote: post #64

paxys wrote: post #61

Earlier quoted context omitted.

"You never know..." is the worst form of security, and makes systems less secure overall. Passwords must be changed every month, just to be safe. They must be 20 alphanumeric characters (with 5 symbols of course), just to be safe. We must pass every 3-letter compliance standard with hundreds of pages of checklists for each. The server must have WAF enabled, because one of the checklists says so. Ask the CIO what actu…

> Ask the CIO what actual threat all this is preventing the CIO is securing his job.

the CIO is securing his job.

Every CIO I have worked for (where n=3) has gotten where they are because they're a good manager, even though they have near-zero current technical knowledge.

The fetishizing of "business," in part through MBAs, has been detrimental to actually getting things done.

A century ago, if someone asked you what you do and you replied, "I'm a businessman. I have a degree in business," you'd get a response somewhere between "Yeah, but what to you actually do" and outright laughter.

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

#78

Post by swiftcoder » Fri, Apr 25, 2025, 3:12 PM UTC

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…

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.

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

#79

Post by krferriter » Fri, Apr 25, 2025, 3:12 PM UTC

gfiorav wrote: post #54

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…

If your web application is relying on Cloudflare filtration of input values to prevent SQL injection, your web application is vulnerable to SQL injection.

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

#80

Post by SonOfLilit » Fri, Apr 25, 2025, 3:13 PM UTC

simonw wrote: post #58

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?

First time something on-prem, maybe F5. Second time AWS.

Oh, I just remembered I had another encounter with the AWS WAF.

I had a Jenkins instance in our cloud account that I was trying to integrate with VSTS (imagine github except developed by Microsoft, and still maintained, nevermind that they own github and it's undoubtedly a better product). Whenever I tried to trigger a build, it worked, but when VSTS did, it failed. Using a REST monitor service I was able to record the exact requests VSTS was making and prove that they work with curl from my machine... after a few nights of experimenting and diffing I noticed a difference between the request VSTS made to the REST monitor and my reproduction with curl: VSTS didn't send a "User-Agent" header, so curl supplied one by default unless I added I think -H "User-Agent:", and therefore did not trigger the first default rule in the AWS WAF, "if your request doesn't list a user agent you're a hacker".

HAHAHA I'VE BEEN WAFFED AGAIN.