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

231–240 of 370 posts

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

#231

Post by afiori »

kiitos wrote: post #217
schnable wrote: post #176

Earlier quoted context omitted.

I don't think so. This rule for example probably block attacks on a dozen old WordPress vulnerabilities.

And a rule that denies everything blocks all vulnerabilities entirely. A false positive from a conservative evaluation of a query parameter or header value is one thing, conceivably understandable. A false positive due to the content of a blog post is something else altogether.

This is a strawman, especially if like the parent claims this was improving security for one of the most popular website backends ever.

Rules like this might very well have had incredible positive impact on ten of thousands of websites at the cost of some weird debugging sessions for dozens of programmers (made up numbers obviously).

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

#232

Post by SonOfLilit »

0xbadcafebee wrote: post #229
immibis wrote: post #180

Earlier quoted context omitted.

They're being downvoted because they're saying the author is incorrect when the author is actually correct.

It's frightening that so many people are convinced the author is correct, when the author never proved they were correct. The author just collected a bunch of correlations and then decided what the cause was. I've been doing this kind of work for many, many years. Just because it looks like it's caused by one thing, doesn't mean it is . Correlation is not causation. That's not just a pithy quip, there's a reason why…

Having had three opportunities in my life to diagnose this exact problem and then successfully resolve it by turning off the WAF rule (see my top level comment) - I don't know you or your work history, but trust me, the author is much closer to the truth here than you are.

edit: Also, someone commented here "it was an irrelevant cf WAF rule, we disabled it". Assuming honesty, seems to confirm that the author was indeed right.

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

#233

Post by pjmlp »

betaby wrote: post #227
pjmlp wrote: post #202

Earlier quoted context omitted.

This is standard practice for years in big corporations. You install software via ticket requests to IT, and devs might have admin rights, but not root, and only temporary. This is nothing new though, back in the timesharing days, where we would connect to the development server, we only got as much rights as required for the ongoing development workflows. Hence why PCs felt so liberating.

It's a standard practice. And at $CURENT_JOB it's driven by semi-literate security folks, definitely not insurance.

Insurance and liability concerns drive the security folks.

Just wait when more countries keep adopting cybersecurity laws for companies liabilities when software doesn't behave, like in any other engineering industry.

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

#234

Post by SonOfLilit »

_1tem wrote: post #212
robertlagrant wrote: post #131

> This case highlights an interesting tension in web security: the balance between protection and usability. This isn't a tension. This rule should not be applied at the WAF level. It doesn't know that this field is safe from $whatever injection attacks. But the substack backend does. Remove the rule from the WAF (and add it to the backend, where it belongs) and you are just as secure and much more usable. No tension…

I would say it’s a decent security practice to apply WAF as a blanket rule to all endpoints and then remove it selectively when issues like this occur. It’s much, much, harder to evaluate every single public facing endpoint especially when hosting third party software like Wordpress with plugins.

I don't agree. WAFs usually add more attack surface than they remove.

https://www.macchaffee.com/blog/2023/wafs/

Of course, Wordpress is basically undefendable, so I'd never ever host it on a machine that has anything else of value (including e.g. db credentials that give access to much more than the public content on the WP installation).

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

#235

Post by SonOfLilit »

nicoledevillers wrote: post #121

it was a cf managed waf rule for a vulnerability that doesn't apply to us. we've disabled it.

This comment deserves to be much higher, assuming this user speaks for Substack (no previous submissions or comments, but the comment implies it).

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

#237

Post by bornfreddy »

9x39 wrote: post #215
serial_dev wrote: post #203

Earlier quoted context omitted.

I don’t think locking down slashes support calls because you will now receive support requests anytime someone wants to install something and actually have a good business reason to do so.

Consider the ones you don't get: ones where PCs have to be wiped from customization gone wrong, politics and productivity police calls - "Why is Bob gaming?", "Why is Alice on Discord?". It's about the transition from artisanal hand-configuration to mass-produced fleet standards, and diverting exceptional behavior and customizations somewhere else.

Coupled with protection against executing unknown executables this also actually helps with security. It's not like (most) users know which exe is potentially a trojan.

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

#238

Post by j1elo »

noisem4ker wrote: post #199
swyx wrote: post #183

Earlier quoted context omitted.

i think GP's point is how would you even sanitize the string "OutOfMemoryException" which presumably comes from a trusted system i guess demanding "Structured logs for everything or bust" is the answer? (i'm not a big o11y guy so pardon me if this is obvious)

"o11y" stands for "observability". Numeronyms are evil and we should stop using them.

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?

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

#239

Post by maccard »

josephcsible wrote: post #85
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…

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

In a lot of cases the it people are just following the rules and don’t know this.

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

#240

Post by swyx »

j1elo wrote: post #238
noisem4ker wrote: post #199

Earlier quoted context omitted.

"o11y" stands for "observability". Numeronyms are evil and we should stop using them.

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? come on. the term is 7 years old and is used all over the site. it’s earned it

Post reply on HN