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

141–150 of 370 posts

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

#141

Post by hnlmorg »

jrockway wrote: post #14
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.

Yeah, and this seems like a common Fortune 500 mandatory checkbox. Gotta have a Web Application Firewall! Doesn't matter what the rules are, as long as there are a few. Once I was told I needed one to prevent SQL injection attacks... against an application that didn't use an SQL database. If you push back you'll always get a lecture on "defense in depth", and then they really look at you like you're crazy when you su…

I’m going through exactly this joy with a client right now.

“We need SQL injection rules in the WAF”

“But we don’t have an SQL database”

“But we need to protect against the possibility of partnering with another company that needs to use the same datasets and wants to import them into a SQL database”

In fairness, these people are just trying to do their job too. They get told by NIST (et al) and Cloud service providers that WAF is best practice. So it’s no wonder they’d trust these snake oil salesman over the developers who asking not to do something “security” related.

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

#142

Post by worewood »

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…

There is a tension, but it's between paying enough to developers to actually produce decent code or pay a 3rd-party to firewall the application.

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

#143

Post by manwe150 »

cratermoon wrote: post #135
simonw wrote: post #126

Earlier quoted context omitted.

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.

Sometime in the past few years I saw a new wrinkle: password must be changed every 90 days unless it is above a minimum length (12 or so as best I recall) in which case you only need to change it yearly. Since the industry has realized length trumps dumb "complexity" checks, it's a welcome change to see that encoded into policy.

I think I like this idea that the rotation interval could be made proportional to length, for example doubling the interval with each additional character. Security standards already now acknowledge that forced yearly rotation is a net decrease in security, so this would incentivize users to pick the longest password for which they would tolerate the rotation interval. Is yearly rotation too annoying for you? For merely the effort of going from 12 -> 14 characters, you could make it 4 years instead, or 8 years, 16, and so on.

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

#144

Post by manwe150 »

betaby wrote: post #100
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…

> but a lot of seemingly dumb security policies are due to insurers. I keep hearing that often on HN, however I've personally never seen seen such demands from insurers. I would greatly appreciate if one share such insurance policy. Insurance policies are not trade secrets and OK to be public. I can google plenty of commercial cars insurance policies for example.

You can buy insurance for just about anything, not just cars. Companies frequently buy insurance against various low-probability incidents such as loss of use, fraud, lawsuit, etc.

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

#145

Post by RKFADU_UOFCCLEL »

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…

There's no "trade-off" here. Blocking IPs that send "1337 h4x0r buzzword /etc/passwd" in it is completely naive and obtrusive, which is the modus operandi of the CDN being discussed here. There are plenty of other ways of hosting a website.

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

#146

Post by RKFADU_UOFCCLEL »

p_ing wrote: post #97
krferriter wrote: post #79

Earlier quoted context omitted.

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

Defense in-depth. I would hope few would want a vulnerable web app and simply protect it via a WAF. But just because your web app is 'invulnerable' doesn't mean you should forgo the WAF.

What? If I construct my queries the right way (e.g., not concatenating strings together like it's the year 1990), then I never will want a WAF "helping" me by blocking my users because they have an apostrophe in their name.

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

#147

Post by netsharc »

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…

+++ATH

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

#148

Post by simonw »

betaby wrote: post #100
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…

> but a lot of seemingly dumb security policies are due to insurers. I keep hearing that often on HN, however I've personally never seen seen such demands from insurers. I would greatly appreciate if one share such insurance policy. Insurance policies are not trade secrets and OK to be public. I can google plenty of commercial cars insurance policies for example.

I found an example!

https://retail.direct.zurich.ch/resources/definition/product...

Questionnaire Zurich Cyber Insurance

Question 4.2: "Do you have a technically enforced password policy that ensures use of strong passwords and that passwords are changed at least quarterly?"

Since this is an insurance questionnaire, presumably your answers to that question affect the rates you get charged?

(Found that with the help of o4-mini https://chatgpt.com/share/680bc054-77d8-8006-88a1-a6928ab99a...)

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

#149

Post by SonOfLilit »

eli wrote: post #11
paxys wrote: post #4

This isn't a "security vs usability" trade-off as the author implies. This has nothing to do with security at all. /etc/hosts See, HN didn't complain. Does this mean I have hacked into the site? No, Substack (or Cloudflare, wherever the problem is) is run by people who have no idea how text input works.

It's a text string that is frequently associated with attacks and vulnerabilities. In general you want your WAF to block those things. This is indeed the point of a WAF. Except you also don't want it to get in the way of normal functionality (too much). That is what the security vs usability trade off is. This particular rule is obviously off. I suspect it wasn't intended to apply to the POST payload of user content.…

Your auditor wants your WAF to block those things. _You_, at least I, never ever want to have a WAF at all, as they cause much more harm than good and, as a product category, deserve to die.

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

#150

Post by ycombinatrix »

PhilipRoman wrote: post #124
netsharc wrote: post #19

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

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