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