/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.
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 ended up deploying a WAF to block all these requests, even though it didn't improve security in any meaningful way.
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
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 :)