←back to thread

603 points scalewithlee | 2 comments | | HN request time: 0s | source
Show context
matt_heimer ◴[] No.43794013[source]
The people configuring WAF rules at CDNs tend to do a poor job understanding sites and services that discuss technical content. It's not just Cloudflare, Akamai has the same problem.

If your site discusses databases then turning on the default SQL injection attack prevention rules will break your site. And there is another ruleset for file inclusion where things like /etc/hosts and /etc/passwd get blocked.

I disagree with other posts here, it is partially a balance between security and usability. You never know what service was implemented with possible security exploits and being able to throw every WAF rule on top of your service does keep it more secure. Its just that those same rulesets are super annoying when you have a securely implemented service which needs to discuss technical concepts.

Fine tuning the rules is time consuming. You often have to just completely turn off the ruleset because when you try to keep the ruleset on and allow the use-case there are a ton of changes you need to get implemented (if its even possible). Page won't load because /etc/hosts was in a query param? Okay, now that you've fixed that, all the XHR included resources won't load because /etc/hosts is included in the referrer. Now that that's fixed things still won't work because some random JS analytics lib put the URL visited in a cookie, etc, etc... There is a temptation to just turn the rules off.

replies(14): >>43794129 #>>43794136 #>>43794174 #>>43794203 #>>43794226 #>>43794234 #>>43794368 #>>43794502 #>>43795948 #>>43796540 #>>43798420 #>>43800243 #>>43804110 #>>43805902 #
mjr00 ◴[] No.43794226[source]
> I disagree with other posts here, it is partially a balance between security and usability.

And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in the face that it's bad practice, NIST changed its policy to recommend not regularly rotating passwords over a decade ago, etc., and be totally correct... but they're still going to jack up premiums if you don't do it. So you dejectedly sigh, implement a password expiration policy, and listen to grumbling employees who call you incompetent.

It's been a while since I've been through a process like this, but given how infamous log4shell became, it wouldn't surprise me if insurers are now also making it mandatory that common "hacking strings" like /etc/hosts, /etc/passwd, jndi:, and friends must be rejected by servers.

replies(12): >>43794339 #>>43794401 #>>43794476 #>>43794485 #>>43794676 #>>43794868 #>>43795485 #>>43797735 #>>43799077 #>>43799776 #>>43800796 #>>43802890 #
simonw ◴[] No.43795485[source]
I wish IT teams would say "sorry about the password requirement, it's required by our insurance policy". I'd feel a lot less angry about stupid password expiration rules if they told me that.
replies(1): >>43795721 #
cratermoon ◴[] No.43795721[source]
Sometime in the past few years I saw a new wrinkle: password must be changed every 90 days unless it is above a minimum length (12 or so as best I recall) in which case you only need to change it yearly. Since the industry has realized length trumps dumb "complexity" checks, it's a welcome change to see that encoded into policy.
replies(2): >>43795909 #>>43797373 #
manwe150 ◴[] No.43795909[source]
I think I like this idea that the rotation interval could be made proportional to length, for example doubling the interval with each additional character. Security standards already now acknowledge that forced yearly rotation is a net decrease in security, so this would incentivize users to pick the longest password for which they would tolerate the rotation interval. Is yearly rotation too annoying for you? For merely the effort of going from 12 -> 14 characters, you could make it 4 years instead, or 8 years, 16, and so on.
replies(2): >>43796682 #>>43799061 #
connicpu ◴[] No.43796682[source]
Can confirm when I found out I'd be required to regularly change my password the security of it went down significantly. At my current job when I was a new employee I generated a secure random password and spent a week memorizing it. 6 months later when I found out I was required to change it, I reverted to a variation of the password I used to use for everything years ago with some extra characters at the end that I'll be rotating with each forced change...
replies(2): >>43799133 #>>43799491 #
byproxy ◴[] No.43799133[source]
Why not make use of a password manager?
replies(2): >>43799339 #>>43799599 #
Aeolun ◴[] No.43799339[source]
You can’t open the password manager until your computer is unlocked.
replies(1): >>43799546 #
1. isomorphic- ◴[] No.43799546[source]
You can put the password manager on your phone or another device.
replies(1): >>43799716 #
2. denkmoon ◴[] No.43799716[source]
and now you’re violating a different policy.