Writing "/etc/hosts" breaks the Substack editor

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.

My thought exactly - this isn't an example of balance between "security vs usability" - this is just wrong behaviour.

This is like banning quotes from your website to 'solve' SQL injection...

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. Perhaps just URL parameters.

On a big enough website, users are doing weird stuff all the time and it can be tricky to write rules that stop the traffic you don't want while allowing every oddball legitimate request.

> is run by people who have no idea how text input works

That's a very uncharitable view. It's far more likely that they are simply using some WAF with sane defaults and never caught this. They'll fix it and move on.

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.

"magic quotes" have entered the chat :D

> For example, I worked with a client that had a test suite of about 7000 or so strings that should return a 500 error

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

this causes me pain

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.

with insane defaults FTFY

Why in the world should those be 500 even? Those all are "40x client fuckup".

I guess someone was told, when compiling those strings, that they should observe this known-good implementation (that actually crashed upon receiving such things) and record whatever it returns, and then mandate it of everyone else from now on.

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