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

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

#321

Post by crabbone » Sat, Apr 26, 2025, 12:01 PM UTC

blenderob wrote: post #86

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

Precisely.

This also reminded me, I think in the PHP 3 era, PHP used to "sanitize" the contents of URL requests to blanket combat SQL injections, or perhaps, it was a configuration setting that would be frequently turned on in shared hosting services. This, of course, would've been very soon discovered by the authors of the PHP site and various techniques were employed to circumvent this restriction, overall giving probably even worse outcomes than if the "sanitation" wasn't there to begin with.

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

#322

Post by alpaca128 » Sat, Apr 26, 2025, 12:01 PM UTC

swyx wrote: post #240

j1elo wrote: post #238

Earlier quoted context omitted.

Thanks. My mind started running the random string generator given those restrictions, like a puzzle game. But had no idea of what it meant until you wrote it. Who invented that stupid idea and thought it would be a good one?

because its easily googlable. counter point - people are going to use them, better to expose newbies early and often and then everyone is better off shorthands will always be in demand. we used to say “horseless carriage”, then “automobile”, then “car”. would you rather use Light amplification by stimulated emission of radiation or just “laser”s? etc in the new york times? sure, spell out observability. but on HN? co…

Or we could use words that don't require people to use Google just to be able to read. A dependence on a search engine for reading text is unnecessary.

If you find typing tedious just use autocomplete or other tools instead of making it the readers' problem.

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

#323

Post by MortyWaves » Sat, Apr 26, 2025, 12:01 PM UTC

ycombinatrix wrote: post #150

PhilipRoman wrote: post #124

Earlier quoted context omitted.

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.

Why would someone "sanitize" OutOfMemoryException out of their logs? That is a silly point to make.

Absolutely incredible how dense HN can be and that no one has explained. Obviously that isn’t what they are saying, they are saying it’s profoundly stupid to have the server be controlled by a simple string search at all.

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

#324

Post by phito » Sat, Apr 26, 2025, 12:05 PM UTC

Aeolun wrote: post #265

II2II wrote: post #259

Earlier quoted context omitted.

> 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 the face that it's bad practice, NIST changed its policy to recommend not regularly rotating passwords over a decade ago, etc., and be totally correct... but they're still going to jack up premiums if you don't do it. I would argue that password polici…

> removing the requirement to change passwords every 90 days would encourage very few people to select secure passwords When you don’t require them to change it, you can just assign them a random 16 character string and tell them it’s their job to memorize it.

There's no way I will ever remember it. I will write it down. Let me choose my own password (passphrase if I need to remember it)

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

#325

Post by wvh » Sat, Apr 26, 2025, 12:09 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…

Having worked with PCI-DSS, some rules seem to only exist to appease insurance. When criticising decisions, you are told that passing audits to be able to claim insurance is the whole game, even when you can demonstrate how you can bypass certain rules in reality. High-level security has more to do with politics (my definition) than purely technical ability. I wouldn't go as far as to call it security theatre, there's too much good stuff there that many don't think about without having a handy list, but the game is certainly a lot bigger than just technical skills and hacker vs anti-hacker.

I still have a nervous tick from having a screen lock timeout "smaller than or equal to 30 seconds".

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

#326

Post by gitroom » Sat, Apr 26, 2025, 1:07 PM UTC

The amount of headaches I've had from WAFs blocking legit stuff is unreal. I just wish the folks turning those rules on had to use them for a week themselves.

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

#327

Post by odirf » Sat, Apr 26, 2025, 1:39 PM UTC

mrgoldenbrown wrote: post #29

Everything old is new again :) We used to call this the Scunthorpe problem. https://en.m.wikipedia.org/wiki/Scunthorpe_problem

It is time to add the Substack case to this Wikipedia article.

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

#328

Post by p_ing » Sat, Apr 26, 2025, 1:49 PM UTC

TheDong wrote: post #298

p_ing wrote: post #179

Earlier quoted context omitted.

That's a very narrow view of what a WAF does. You may want to review the OWASP ruleset at https://coreruleset.org/ . However, this is just the ruleset. WAF vendors usually offer features above and beyond OWASP rule parsing. And WAF rules can be tuned. There's no reason an apostrophe in a username or similar needs to be blocked, if it were by a rule.

Okay, I'll look at the "coreruleset" which you say is good. Let's see what's blocked: "Division by zero" anywhere in the response body since that's a php error. Good luck talking about math ([0] and [1]) Common substrings in webshells, all matched as strings in response bodies, rather than parsing HTML, so whatever, don't comment about webshells either [2] Unless the body is compressed, in which case don't apply the…

The issue is you're picking out bits and pieces that /seem/ correct to you, but you don't seem to have experience defending a public website from intrusions.

These rules do in fact work. Like I've said previously, these rules require tuning for your particular website. If I'm "talking about math" then I would modify or disable that rule as needed.

I think this is the forest you're missing. WAF isn't "install it and walk away". WAF needs to be tested in conjunction with your release, like any other code would.

The WAF can and does protect against attacks your code would never think of. It also /logs requests/ in a way your web server will not, making it invaluable for auditing.

And when running 3rd party software that has a function you cannot control, but need to prevent, WAFs can do that, too. I have a particular query string that must work from an internal but not external network while external/internal users leverage the same URL -- WAF can do that with a custom rule examining the query string and denying access to the outside world.

Or if I need to prevent [AI] bot scraping. WAF can do that with a couple of clicks.

WAF also unloads the web server from malicious traffic. Instead of having to size up or out a web server, I can have a WAF appliance prevent that traffic from ever reaching the server.

> Every WAF ruleset I've read so far

You don't appear to have any experience with implementation or operation of a WAF, but are attempting to be authoritative and dismiss a WAFs utility.

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

#329

Post by toogan » Sat, Apr 26, 2025, 1:56 PM UTC

The title would be improved with "Writing the string ...". I first read it as "Writing the file" which was pretty weird.

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

#330

Post by lsofzz » Sat, Apr 26, 2025, 2:45 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…

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

I agree. There is a business opportunity here. Right in the middle of your sentences.

Hint: Context-Aware WAF.

Many platforms have emerged in the last decade - some called it smart WAF, some called it nextgen WAF.. All vaporware garbage that consumes tons and tons of system resource and still manages to do a shit job of _actually_ WAF'ing web requests.

To be truly context-aware, you need to compute a priori about the situation - the user, the page, the interactions etc.