4 ms·
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 th
by paxys 2y ago
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.
- macspoofing 2y agoMy thought exactly - this isn't an example of balance between "security vs usability" - this is just wrong behaviour.
- orlp 2y agoThis is like banning quotes from your website to 'solve' SQL injection...
- betenoire 2y ago"magic quotes" have entered the chat :D
- eli 2y agoIt'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.
- SonOfLilit 2y agoYour 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.
- mystifyingpoi 2y ago> 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.
- immibis 2y agowith insane defaults FTFY
- gav 2y agoIt'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.
- krferriter 2y ago> 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
- WesolyKubeczek 2y agoWhy 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.
- ta1243 2y agoWhat is their desired behaviour if not a 404? A 500? a FIN? a RST?
- gav 2y agoThe 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 :)