←back to thread

Writing "/etc/hosts" breaks the Substack editor

(scalewithlee.substack.com)
642 points scalewithlee | 2 comments | 25 Apr 25 13:48 UTC | HN request time: 0.009s | source
Show context
paxys ◴[25 Apr 25 14:09 UTC] No.43793735[source]▶
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.

replies(5): >>43793752 #>>43793805 #>>43793852 #>>43793880 #>>43794047 #
gav ◴[25 Apr 25 14:36 UTC] No.43794047[source]▶
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)
  /../..//../..//../..//../winnt/system32/netstat.exe?-a
We "failed" and were not in compliance as you could make a request containing one of those strings--ignoring that neither Apache, SQL, or Windows were in use.

We ended up deploying a WAF to block all these requests, even though it didn't improve security in any meaningful way.

replies(3): >>43794824 #>>43804273 #>>43819015 #
1. ta1243 ◴[28 Apr 25 08:41 UTC] No.43819015[source]▶
What is their desired behaviour if not a 404? A 500? a FIN? a RST?
replies(1): >>43823337 #
2. gav ◴[28 Apr 25 16:39 UTC] No.43823337[source]▶
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 :)