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

161–170 of 370 posts

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

#161

Post by teraflop »

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.

The point is not to sanitize known strings like "OutOfMemoryException". The point is to sanitize or (preferably) escape any untrusted data that gets logged, so that it won't be confused for something else.

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

#162

Post by godelski »

I don't get it. Why aren't those files just protected so they have no read or write permissions? Isn't this like the standard way to do things? Put the blog in a private user space with minimal permissions.

Why would random text be parsed? I read the article but this doesn't make sense to me. They suggested directory transversal but your text shouldn't have anything to do with that and transversal is solved by permission settings

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

#163

Post by reverendsteveii »

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

"I wonder why it's called Scunthorpe....?"

sits quietly for a second

"Oh nnnnnnnooooooooooooooo lol!"

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

#164

Post by p_ing »

krferriter wrote: post #110
p_ing wrote: post #97

Earlier quoted context omitted.

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.

But what is being defended against? This is blocking legitimate user behavior. Would it be defense in depth to also prohibit semicolons or two consecutive hyphen characters in all content? If your app is constructing paths to read from the server's filesystem based on substrings contained within client-provided field values, throwing an error if `"/etc/hosts"` appears in any input is not going to save you.

Unknown or unforeseen attacks. The WAF ruleset can be updated much faster than code. WAFs also provide flexibility in how requests are responded to, or even disallow access from IP ranges, certain browsers, etc.

WAFs do throw false positives and do require adjustments OOTB for most sites, but you’re missing the forest by focusing on this single case.

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

#165

Post by jandrese »

righthand wrote: post #31

Similar: Writing `find` as the first word in your search will prevent Firefox from accepting the “return” key is pressed. Pretty annoying.

Are you sure you don't have a custom search rule configured in Firefox? I just tried this on my local instance and there was no problem.

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

#166

Post by immibis »

krferriter wrote: post #76
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 don't get why you'd have SQL injection filtering of input fields at the CDN level. Or any validation of input fields aside from length or maybe some simple type validation (number, date, etc). Your backend should be able to handle arbitrary byte content in input fields. Your backend shouldn't be vulnerable to SQL injection if not for a CDN layer that's doing pre-filtering.

Because someone said "we need security" and someone else said "what is security" and someone else said "SQL injection is security" and someone looked up SQL injections and saw the word "select" and "insert".

WAFs are always a bad idea (possible exception: in allow-but-audit mode). If you knew the vulnerabilities you'd protect against them in your application. If you don't know the vulnerabilities all you get is a fuzzy feeling that Someone Else is Taking Care of it, meanwhile the vulnerabilities are still there.

Maybe that's what companies pay for? The feeling?

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

#167

Post by jrockway »

formerly_proven wrote: post #140
elevation wrote: post #62

Earlier quoted context omitted.

Doesn't it also add latency to every request?

So does running McAfee on every POST body but some places really wanna do that regardless. (I at least hope the scanner isn't running in the kernel for this one).

Yeah, we were asked to do this at my last job by some sort of security review. This one doesn't bother me as much. "Display 'network error' whenever a user uploads a file containing 'SELECT *'" is a bad user experience. "Some files in this repository have been flagged as containing a virus and are not visible in the web interface until allowed by an administrator," is OK with me, though.

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

#168

Post by immibis »

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.

My defense in depth blocks Content-Length that's a prime number or divisible by 5. Can't be too safe!

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

#169

Post by kiitos »

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. 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 loop here, but it seems to me that any WAF that's triggered when the string "/etc/hosts" is literally anywhere in the content of a requested resource, is pretty obviously broken.

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

#170

Post by gfiorav »

wat10000 wrote: post #133
gfiorav wrote: post #54

Earlier quoted context omitted.

I agree. From a product perspective, I would also support the decision. Should we make the rules more complex by default, potentially overlooking SQL injection vulnerabilities? Or should we blanket prohibit anything that even remotely resembles SQL, allowing those edge cases to figure it out? I favor the latter approach. That group of Cloudflare users will understand the complexity of their use case accepting SQL in…

Sorry, we have to reject your comment due to security. The text "Cloudflare s" is a potential SQL injection.

You know, I get the spirit of this criticism. But, specially in the age of AI, we're going to get thousands of barely reviewed websites on Cloudflare.

If you know what you're doing, turn these protections off. If you don't, there's one less hole out there.

Post reply on HN