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

351–360 of 370 posts

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

#351

Post by patrakov »

RKFADU_UOFCCLEL wrote: post #146
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.

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.

> If I construct my queries the right way (e.g., not concatenating strings together like it's the year 1990)...

(in the anti-WAF camp but playing a pedant here)

In your Django app, you indeed follow the best practices and don't concatenate strings together and so think that this security theater doesn't apply. Yet, this is precisely how Django ORM works under the hood, and SQL injections are periodically found there.

The real solution here is to subscribe to the django-announce list and update Django, or backport the fix manually.

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

#352

Post by Wowfunhappy »

int_19h wrote: post #317
Wowfunhappy wrote: post #191

Earlier quoted context omitted.

The insurance people are not a part of the company, so I'm not sure who would be offended. I wouldn't be mean about it. I'm imagining adding a line to the email such as: > (Yes, I know this is annoying, but it's required by our insurance company.) What is the insurance company going to do, jack up our rates because we accurately stated what their policy was?

The problem is that this particular insurance company was picked by someone who does work in yours.

This seems like a pretty awful place to work if my bosses have such fragile egos they can't handle me saying "our insurance requires us to do X". I'm not even really passing judgement on whether X is good or bad.

I'm not saying you're wrong, I've never worked in a company this large (except for a brief internship), or in IT specifically. But also, like, come on people, grow up.

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

#353

Post by Too »

Matumio wrote: post #320
Too wrote: post #299

Earlier quoted context omitted.

This is actually a better solution, replacing dangerous words with placeholders, instead of blocking the whole payload. That at least gives the user some indication of what is going on. Not that I'm for any such WAF filters in the first place, just if having to choose between the lesser of two evils I'd choose the more informative.

Not so sure. Imagine you have a base64 encoded payload and it just happens to encode the forbidden word. Good luck debugging that, if the payload only gets silently modified. I suddenly understand why it makes sense to integrity-check a payload that is already protected by all three of TLS, TCP checksum and CRC.

Good point, i take take that back. Having payload mutated would indeed be even more scary. Even more so if it actually contains real queries, imagine what could happen if /etc/hosts becomes /etc/*.

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

#354

Post by afiori »

kiitos wrote: post #349
afiori wrote: post #231

Earlier quoted context omitted.

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

Look, any WAF that blocks a document like /etc/hosts is a file on Unix hosts is pretty clearly broken. And you can't meaningfully measure product metrics like impact for fundamentally broken products.

> is pretty clearly broken

agree

> And you can't meaningfully measure product metrics like impact for fundamentally broken products

disagree

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

#355

Post by TRiG_Ireland »

crabbone wrote: post #321
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 p…

The days of addslashes() and stripslashes()!

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

#357

Post by Anamon »

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…

Yes to smart filtering at the right layer. The whole reverse DNS checks et al. are so effective. I recently moved my personal mailbox from a host who didn't do these kinds of checks to one that does. My received spam volume instantly went from about 20 a day (across all my aliases) to less than 1 a week.

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

#358

Post by ta1243 »

gav wrote: post #39
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 more so that Cloudflare has a WAF product that checks a box for security and makes people who's job it is to care about boxes being checked happy. For example, I worked with a client that had a test suite of about 7000 or so strings that should return a 500 error, including /etc/hosts and other ones such as: ../../apache/logs/error.log AND%20(SELECT%208203%20FROM%20(SELECT(SLEEP(5)))xGId) /../..//../..//../..//.…

What is their desired behaviour if not a 404? A 500? a FIN? a RST?

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

#359

Post by tryauuum »

godelski wrote: post #284
Macha wrote: post #278

Earlier quoted context omitted.

Misconfiguring your web server such that example.com/../../etc/passwd returned the actual file was a common vulnerability in the early 00s. Or cgi scripts that worked with real file paths but accepted any path WAFs blocking the string with the filename then is the "to make sure nobody ever accidentally leaves your gate open, we've replaced it with a concrete wall" solution to this problem. You might never have this p…

> directory transversal attack There's some serious miscommunication going on. I'm quite willing to believe it is from my end, but I thought I explained earlier that I'm well aware of directory transversal. The example did not clarify things to me when the author mentioned it I asked why setting permissions was not a sufficient solution. Is someone gaining root? How? I understand there's the user visiting substack an…

> I asked why setting permissions was not a sufficient solution.

/etc/passwd is readable by design by every user in Linux. And you have it even inside the containers. If you set permissions to "readable by root only" normal programs won't be able to map user names to ids and your application might die

In modern linux this file doesn't contain any passwords, the only thing the attacker can gain by reading it is learning some usernames

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

#360

Post by gav »

ta1243 wrote: post #358
gav wrote: post #39

Earlier quoted context omitted.

It's more so that Cloudflare has a WAF product that checks a box for security and makes people who's job it is to care about boxes being checked happy. For example, I worked with a client that had a test suite of about 7000 or so strings that should return a 500 error, including /etc/hosts and other ones such as: ../../apache/logs/error.log AND%20(SELECT%208203%20FROM%20(SELECT(SLEEP(5)))xGId) /../..//../..//../..//.…

What is their desired behaviour if not a 404? A 500? a FIN? a RST?

The desired result is a 500 so it's possible to audit.

As much as this is a pain, the alternative can be more painful.

I used to have a client that would forward me an email from their security team every six weeks saying "we found a SQL injection issue with your site, can you look into this and confirm that it's fixed?" and I'd reply back saying "that not possible" and they'd go "ok, we've marked this as a false positive".

Eventually I got bored of having the same conversation over and over, so I asked them to show what they were finding. It turned out their scan would do the following:

  html1 = request("https://example.com/search?query=test")
  html2 = request("https://example.com/search?query=test' or 1=1--")
  if (html1 != html2) 
    sql_injection_vulnerable = true
Which of course is total nonsense, just because it returns different content doesn't mean anything.

This is a perfect use case for a WAF, I can stick one in front and then have it return 500s for all these requests and not worry about it any more.

In our case, we didn't have a WAF, but they had a obvious User-Agent, and it turns out that blocking all of their requests passed the scan too :)

Post reply on HN