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

211–220 of 370 posts

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

#211

Post by _1tem »

johnklos wrote: post #112

Content filtering should be highly context dependent. If the WAF is detached from what it's supposed to filter, this happens. If the WAF doesn't have the ability to discern between command and content contexts, then the filtering shouldn't be done via WAF. This is like spam filtering. I'm an anti-spam advocate, so the idea that most people can't discuss spam because even the discussion will set off filters is quite o…

SPF and DKIM are now more commonly implemented correctly by spammers than by major email providers.

https://news.ycombinator.com/item?id=43468995

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

#212

Post by _1tem »

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.

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

#213

Post by HappMacDonald »

vladvasiliu wrote: post #103
mjr00 wrote: post #98

Earlier quoted context omitted.

> 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 the insurer requested something unreasonable, you'd go to a different insurer. It's a competitive market after all. But most of the complaints about incompetent security practices boil down to min…

The issue is that the Finance dept will show up and ask why you chose the more expensive insurance. Sure, if you're able to show how much the annoyances of the cheaper company would cost you, they'd probably shut it. But I'd argue it's not that easy. Plus, all these annoyances aren't borne by the security team, so they don't care that much in the end.

My first thought might be to put together a report showing the cost that the cheaper insurance would impose upon the organization which the more expensive up-front option is saving you. Perhaps even serve that up as a cost-savings the finance department is free to then take credit for, I'unno. :P

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

#214

Post by serial_dev »

wavemode wrote: post #159
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.

No, that logic doesn't follow. If your application is so hopelessly vulnerable as to benefit from such naive filtering of the text "/etc/hosts, then your application is still going to be vulnerable in precisely the same ways, with just slightly modified inputs. It is net zero for security and net negative for user experience, so having it is worse than not having it.

Net zero for security might be generous.

The way I assume it works in practice on a real team is that after some time, most of your team will have no idea how the WAF works and what it protects against, where and how it is configured… but they know it exists, so they will no longer pay attention to security because “we have a tool for that”, especially when they should have finished that feature a week ago…

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

#215

Post by 9x39 »

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

Earlier quoted context omitted.

A trend for corporate workstations is moving closer to a phone with a locked-down app store, with all programs from a company software repo. Eliminating everything but a business's industry specific apps, MS Office, and some well-known productivity tools slashes support calls (no customization!) and frustrates cyberattacks to some degree when you can't deploy custom executables.

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.

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

#216

Post by serial_dev »

simonw wrote: post #50

"How could Substack improve this situation for technical writers?" How about this: don't run a dumb as rocks Web Application Firewall on an endpoint where people are editing articles that could be about any topic, including discussing the kind of strings that might trigger a dumb as rocks WAF. This is like when forums about web development implement XSS filters that prevent their members from talking about XSS! Learn…

Surprisingly simple solution

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

#217

Post by kiitos »

schnable wrote: post #176
kiitos wrote: post #169

Earlier quoted context omitted.

> I disagree with other posts here, it is partially a balance between security and usability. You never know what service was implemented with possible security exploits and being able to throw every WAF rule on top of your service does keep it more secure. Its just that those same rulesets are super annoying when you have a securely implemented service which needs to discuss technical concepts. I might be out of the…

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.

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

#218

Post by pmarreck »

ryandrake wrote: post #60
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…

This looks like a variation of the Scunthorpe problem[1], where a filter is applied too naively, aggressively, and in this case, to the wrong content altogether. Applying the filter to "other stuff" sent to and among the servers might make sense, but there doesn't seem to be any security benefit to filtering actual text payload that's only going to be displayed as blog content. This seems like a pretty cut and dried…

Correct. And a great example of it.

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

#219

Post by thayne »

As soon as I saw the headline, I knew this was due to a WAF.

I worked on a project where we had to use a WAF for compliance reasons. It was a game of wack-a-mole to fix all the places where standard rules broke the application or blocked legitimate requests.

One notable, and related example is any request with the string "../" was blocked, because it might be a path traversal attack. Of course, it is more common that someone just put a relative path in their document.

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

#220

Post by ZeroTalent »

simonw wrote: post #50

"How could Substack improve this situation for technical writers?" How about this: don't run a dumb as rocks Web Application Firewall on an endpoint where people are editing articles that could be about any topic, including discussing the kind of strings that might trigger a dumb as rocks WAF. This is like when forums about web development implement XSS filters that prevent their members from talking about XSS! Learn…

hire a cybersec person. I don't think they one.
Post reply on HN