4 ms·

There's a problem with viewing security as a "checklist" problem, it treats everything as binary, black or white problem/solutions. In reality, this is _far_ fr

by nmjohn 11y ago

There's a problem with viewing security as a "checklist" problem, it treats everything as binary, black or white problem/solutions. In reality, this is _far_ from the case. For example: > Is TLS1.2 the only supported protocol? Do you know what the implications are from actually implementing that? One probably should do additional research before making that decision. > Have you ensured that your content cannot be embedded in a frame on another website? X-Frame-Options isn't the only way to achieve that. > Have you ensured that the Internet Explorer content sniffer is disabled? This really is only relevant if your site is hosting untrusted content. > Are you using fail2ban to throttle ssh login attempts? > Have you disabled password-based login over ssh, and only allowed key-based login? The first really is of debatable value if the second is also used. > Do forms set a cross-site request forgery cookie? Cookies are not the only way to do this. More common, in my experience, is including the csrf token in the dom (either in a form field as a "hidden" input or as a meta tag) > Do you have an account recovery flow? Delete it immediately. Lol. It's a great checklist for someone who knows what every item on the list is and more importantly, _why_ it is on the list - but it is not something that should be blindly followed.

ajkjk 11y ago
And yet this is so much more useful than the hundreds of pages of blog posts and security advisories that have to be individually a) found and b) understood in order to do security correctly on even a simple website. Yes, I agree that an expandable "explanation and subtleties" section would be wise, but I'm very glad this exists even without.
erikpukinskis 11y ago
> This really is only relevant if your site is hosting untrusted content. I thought designing for security meant both removing privileges and preventing escalation of privileges? I might think my site doesn't host untrusted content, but I might turn out to be wrong about that. It's worth thinking about what checklists are traditionally used for: Checklists are a form of risk mitigation that comes out of the disaster investigation world (the FAA is the checklist OG in my mind). The idea is not to create a document that handles every possible situation and every possible corner case, preventing the need for human thought or expertise. The idea is to build up, over a period of time, lists of crucial things which a) have some chance of getting forgotten and b) can't be constrained through design and put them in lists small enough to tick through regularly. It's a way of catching brain farts before they kill someone, not an attempt to replace proper engineering.
dsacco 11y ago
Good comment. To expand on this in particular, as I haven't seen anyone else mention it: > Do forms set a cross-site request forgery cookie? Some legitimate forms of CSRF mitigation do utilize a cookie, but the checklist is dangerously misleading as worded. An anti-CSRF token in a cookie will do absolutely nothing on its own - it needs to either be in a header or the DOM, as you mentioned. Any forged request an attacker compels a victim to send will include all cookies, not just the session cookie, rendering this protection useless.
newman314 11y ago
I've always said "security, just like disaster recovery, is a lifestyle, not a checklist".
movedx 11y ago
>> Are you using fail2ban to throttle ssh login attempts? >> Have you disabled password-based login over ssh, and only allowed key-based login? > The first really is of debatable value if the second is also used. Actually, no. It makes perfect to block repeat offenders because they might get lucky; they might be exploiting an RCE you're not aware of that takes multiple steps; and they could be trying to DoS that server by filling the logs and thus your disk (and with most people using default 10GB disks on their VMs these days, this isn't too hard to imagine.) Besides, the right answer is: use bastion hosts to proxy SSH connections, preventing them from the outside world, and also port knocking :-)
- nmjohn 11y ago
  > Besides, the right answer is: use bastion hosts to proxy SSH connections, preventing them from the outside world Agreed > It makes perfect to block repeat offenders because they might get lucky No, just no, please don't spread this nonsense. There is no such thing as "lucky" when the probably being discussed is 1 in (2^4096 - 1). > they might be exploiting an RCE you're not aware of that takes multiple steps I'll take my chances. If unauthed RCE exists in SSH (regardless of number of attempts required) there are far more serious implications than any server I manage. Additionally, I'm curious if you have an existing CVE where this kind of exploit has ever been discovered. > they could be trying to DoS that server by filling the logs and thus your disk ... this isn't too hard to imagine Hard to imagine? No. have I ever actually seen in the real world? Also no. Even if one server happened to be dos'ed by this, not a big concern, that's why you run multiple redundant servers behind a load balancer. The only viable attacks would be random in nature since attackers have no idea what the IPs of your actual app servers are. (And if someone can mount an attack that can determine them, you probably have bigger problems then a dos attack from ssh logs) All in all, I feel like this just strengthens my original point, of viewing security as a checklist is a dangerous approach, one needs to actually understand what they are doing. I'm all for layered security, but the problem with using it just because "why not" is that this methodology leads to an environment where there is so much "stuff" nobody knows what is secure, what is not secure, and what strange dependencies were the only reason something was secure in the first place. As far as security goes, everything should have a well-defined purpose.

by nmjohn 11y ago

ajkjk 11y ago

And yet this is so much more useful than the hundreds of pages of blog posts and security advisories that have to be individually a) found and b) understood in order to do security correctly on even a simple website. Yes, I agree that an expandable "explanation and subtleties" section would be wise, but I'm very glad this exists even without.

erikpukinskis 11y ago

> This really is only relevant if your site is hosting untrusted content. I thought designing for security meant both removing privileges and preventing escalation of privileges? I might think my site doesn't host untrusted content, but I might turn out to be wrong about that. It's worth thinking about what checklists are traditionally used for: Checklists are a form of risk mitigation that comes out of the disaster investigation world (the FAA is the checklist OG in my mind). The idea is not to create a document that handles every possible situation and every possible corner case, preventing the need for human thought or expertise. The idea is to build up, over a period of time, lists of crucial things which a) have some chance of getting forgotten and b) can't be constrained through design and put them in lists small enough to tick through regularly. It's a way of catching brain farts before they kill someone, not an attempt to replace proper engineering.

dsacco 11y ago

Good comment. To expand on this in particular, as I haven't seen anyone else mention it: > Do forms set a cross-site request forgery cookie? Some legitimate forms of CSRF mitigation do utilize a cookie, but the checklist is dangerously misleading as worded. An anti-CSRF token in a cookie will do absolutely nothing on its own - it needs to either be in a header or the DOM, as you mentioned. Any forged request an attacker compels a victim to send will include all cookies, not just the session cookie, rendering this protection useless.

newman314 11y ago

I've always said "security, just like disaster recovery, is a lifestyle, not a checklist".

movedx 11y ago

>> Are you using fail2ban to throttle ssh login attempts? >> Have you disabled password-based login over ssh, and only allowed key-based login? > The first really is of debatable value if the second is also used. Actually, no. It makes perfect to block repeat offenders because they might get lucky; they might be exploiting an RCE you're not aware of that takes multiple steps; and they could be trying to DoS that server by filling the logs and thus your disk (and with most people using default 10GB disks on their VMs these days, this isn't too hard to imagine.) Besides, the right answer is: use bastion hosts to proxy SSH connections, preventing them from the outside world, and also port knocking :-)

nmjohn 11y ago
> Besides, the right answer is: use bastion hosts to proxy SSH connections, preventing them from the outside world Agreed > It makes perfect to block repeat offenders because they might get lucky No, just no, please don't spread this nonsense. There is no such thing as "lucky" when the probably being discussed is 1 in (2^4096 - 1). > they might be exploiting an RCE you're not aware of that takes multiple steps I'll take my chances. If unauthed RCE exists in SSH (regardless of number of attempts required) there are far more serious implications than any server I manage. Additionally, I'm curious if you have an existing CVE where this kind of exploit has ever been discovered. > they could be trying to DoS that server by filling the logs and thus your disk ... this isn't too hard to imagine Hard to imagine? No. have I ever actually seen in the real world? Also no. Even if one server happened to be dos'ed by this, not a big concern, that's why you run multiple redundant servers behind a load balancer. The only viable attacks would be random in nature since attackers have no idea what the IPs of your actual app servers are. (And if someone can mount an attack that can determine them, you probably have bigger problems then a dos attack from ssh logs) All in all, I feel like this just strengthens my original point, of viewing security as a checklist is a dangerous approach, one needs to actually understand what they are doing. I'm all for layered security, but the problem with using it just because "why not" is that this methodology leads to an environment where there is so much "stuff" nobody knows what is secure, what is not secure, and what strange dependencies were the only reason something was secure in the first place. As far as security goes, everything should have a well-defined purpose.