it was a cf managed waf rule for a vulnerability that doesn't apply to us. we've disabled it.
Writing "/etc/hosts" breaks the Substack editor
121–130 of 370 posts
Re: Writing "/etc/hosts" breaks the Substack editor
#122Earlier quoted context omitted.
> 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…
It's a relatively recent change, too. Transition from "the executives and managers mostly came up through 10-25 years of doing 'lower' jobs in the company, and very much know how the business actually works" to "we hire MBAs to those roles directly" was throughout the '70s-'90s.
Finance and business grads have really taken over the economy, not just through technocratic "here's how to do stuff" advice but by personally taking all the reigns of power. They're even hard at work taking over medicine and pushing doctors out of the work-social upper-middle-class. Already did it with professors. Lawyers seem safe, so far.
Re: Writing "/etc/hosts" breaks the Substack editor
#123Earlier 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…
Why wouldn't the IT people just tell the grumbling employees that exact explanation?
In small orgs that might happen, in large orgs it's some game of telephone where the insurance requirements are forwarded to the security team which makes the policies which are enforced by several layers of compliance which come down on the local IT department.
The underlying purpose of the rules and agency to apply the spirt rather than the letter gets lost early in the chain and trying to unwind it can be tedious.
Re: Writing "/etc/hosts" breaks the Substack editor
#124Reminds me of an anecdote about an e-commerce platform: someone coded a leaky webshop, so their workaround was to watch if the string "OutOfMemoryException" shows up in the logs, and then restart the app. Another developer in the team decided they wanted to log what customers searched for, so if someone typed in "OutOfMemoryException" in the search bar...
Careless analysis of free-form text logs is an underrated way to exploit systems. It's scary how much software blindly logs data without out of band escaping or sanitizing.
Re: Writing "/etc/hosts" breaks the Substack editor
#125I ran into a similar issue with OpenRouter last night. OpenRouter is a “switchboard” style service that provides a single endpoint from which you can use many different LLMs. It’s great, but last night I started to try using it to see what models are good at processing raw HTML in various ways. It turns out OpenRouter’s API is protected by Cloudflare and something about specific raw chunks of HTML and JavaScript in t…
Did you report it?
Not yet, other than on X, because the project's comms is oriented around Discord which involves some hoop jumping.
(Update: On the way to doing that, I decided to run my tests again and they now work without Cloudflare being touchy, so I'll keep an eye on it!)
(Update 2: They just replied to me on X and said they had fixed their Cloudflare config - happy days!)
Re: Writing "/etc/hosts" breaks the Substack editor
#126The 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…
I wish IT teams would say "sorry about the password requirement, it's required by our insurance policy". I'd feel a lot less angry about stupid password expiration rules if they told me that.
Re: Writing "/etc/hosts" breaks the Substack editor
#127Does 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.
Every security solution can only stop a certain fraction of attacks.
Re: Writing "/etc/hosts" breaks the Substack editor
#128Earlier quoted context omitted.
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.
“attacker had used a shoe bomb”
It’s even dumber than that. An attacker tried and failed to use a shoe bomb, and yet his failure has caused untold hours of useless delay for over 13 years now.
Re: Writing "/etc/hosts" breaks the Substack editor
#129Earlier quoted context omitted.
Doesn't it also add latency to every request?
I think the main point is the WAF companies must have lobbied to get that into the checklist the main point is you need to pay a third party
You can call your existing reverse proxy a WAF to check this checklist item. (Your point still stands, on the median companies may opt to purchase a WAF for various reasons.)
Re: Writing "/etc/hosts" breaks the Substack editor
#130Earlier quoted context omitted.
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…
>guess you're putting in a WAF, like it or not. Install the WAF crap, and then feed every request through rot13(). Everyone is happy!
now you've banned several different arbitrary strings!