Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Developer Security Checklist

simplesecurity.sensedeep.com

Post reply on HN
Print view View original

111–120 of 249 posts

Re: Web Developer Security Checklist

#111

Post by brlewis »

aeronautic wrote: post #91
badminton1 wrote: post #89

Earlier quoted context omitted.

But all the objects remain leaked even if the request connection ends. And if the request stream got piped into another stream the problem can become more severe. Usually error events propagate through piped streams, but that largely depends on the order in which the event handlers were defined.

Are you sure the objects remain leaked when a connection disconnect comes through? I don't have hard data on that. Depending on the node web framework (express, ...) they may handle that differently and may have timeouts to cleanup. I'd love to get a firm answer on this one.

I'd love a firm answer too, but I'm too lazy to write up code that puts request objects in a WeakSet and checks for when the set gets smaller. I hope someone else does it. :-)

Re: Web Developer Security Checklist

#112

Post by edraferi »

aeronautic wrote: post #98
stephenr wrote: post #96

Earlier quoted context omitted.

So your solution to fixing a basic ops problem 'software package A was exposed to the internet with(out|effectively no) auth' is: encrypt shit in an ORM layer and destroy your ability to do anything beyond absolute string comparison queries. No thanks.

No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive. And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.

This is an interesting solution, thanks for sharing. This would be a cool feature to build into open source ORMs.

Re: Web Developer Security Checklist

#113

Post by spydum »

nkozyra wrote: post #110
brlewis wrote: post #109

Earlier quoted context omitted.

As far as I can tell the only threat this is protecting against is someone physically pulling the drive and walking off with it. Are you saying that that threat isn't worth protecting against?

Every potential threat should be considered, but weighed against likelihood when prioritizing. Sometimes you make cost/benefit consolations. 100% airtight would be great, but 100% airtight doesn't actually exist. Most organizations with finite resources have to make risk/reward decisions when there are as many threats as there are with web development.

The cost for encryption at rest is single digit percentages these days.

I push for encryption at rest on ANY cloud provider storage for one main reason: I have no control over their disk disposal or reuse mechanisms. They can claim they wipe the data, but I have no way to test that reliably.

As for disk encryption plus FS encryption, keep in mind in AWS or Azure, it's possible for a misconfigured IAM or SPN to leak access to the disk blob.. If it was encrypted with a key separately, the risk is mitigated. Again, it's just too easy to implement on almost every cloud provider thes days.

Re: Web Developer Security Checklist

#115

Post by EGreg »

aeronautic wrote: post #98
stephenr wrote: post #96

Earlier quoted context omitted.

So your solution to fixing a basic ops problem 'software package A was exposed to the internet with(out|effectively no) auth' is: encrypt shit in an ORM layer and destroy your ability to do anything beyond absolute string comparison queries. No thanks.

No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive. And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.

This is a good idea, but only for fields which can never be used in range based index lookups.

Re: Web Developer Security Checklist

#116

Post by spydum »

jwr wrote: post #60

I do not like this list. > [ ] Use minimal privilege for the database access user account. Don’t use the database root account. This advice seems outdated. In general, every significant security breach will get the attacker root access. Playing games with database accounts gets you no security at all, while introducing lots of friction and headache.

Sorry, you don't throw away mitigation techniques because they aren't foolproof. This is still excellent advice. Stop using sa and root accounts for your apps.

Re: Web Developer Security Checklist

#118

Post by EGreg »

viraptor wrote: post #74
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

> ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? Data at rest means data on the disk. (so basically LUKS or similar partition / FDE) In virtualised environments it may not obvious, but the disk you're running on can still be accessed in various ways. Here are some examples (not a complete list): - VM…

You should see our ORM. It tries to highly discourage text queries:

https://qbix.com/platform/guide/database

Re: Web Developer Security Checklist

#119

Post by spydum »

It is shocking to me to see how many developers giving this checklist a hard time. Every single item is solid advice and what I would have presumed sane people considered common sense/best practice.

Just goes to show how bad a job we have done in the InfoSec world of educating developers.

Re: Web Developer Security Checklist

#120

Post by DamonHD »

atemerev wrote: post #104
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

I think, the author is right, and you might be not. "Data at rest" means the data that you have no intention of querying soon. Which implies "hot" / "cold" data partitioning, which is usually a good idea. Can be complicated, but commonly encountered in financial backends. Two layers of encryption can be better than one (if logically and temporarily separated). Encryption algorithms are usually not a problem; credenti…

All significant modules, whether facing the Internet or internal to a large system, should validate their inputs to prevent propagation of BadThings(TM).

You can choose how much to validate, which is probably more in the former case, but it should be done.

I can't tell you the number of horrors I'm sure we've stopped in (for example) investment banking pricing by avoiding trying to do calculations on junk when the junk was easy to spot. (We also added one or two, eg when one set of interest rates went above 100%, but that's an after-dinner story!)

Post reply on HN