Live data from Hacker News

Web Developer Security Checklist

simplesecurity.sensedeep.com

41–50 of 249 posts

Re: Web Developer Security Checklist

#41
post #39

A largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure. For example, this code was from a guy in Stack Overflow: ... function (req, res, next) { if (err) return console.log(err) What will that piece of code do? Leak the request object, the response object, including the underlyin…

> make your server run out of sockets and memory Do you mind explaining why the code causes this?

Because when you handle a request, you need either respond to it or close it. If you don't close it (e.g: res.end, res.send, ...) the connection remains open. Also all the memory allocated for that request stays around without being collected.

Re: Web Developer Security Checklist

#42
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?

Most database encryption is "transparent", meaning the applications won't even be aware that their database is encrypted. Here is an example:

https://docs.microsoft.com/en-us/sql/relational-databases/se...

Re: Web Developer Security Checklist

#43
post #39

Earlier quoted context omitted.

> make your server run out of sockets and memory Do you mind explaining why the code causes this?

Because when you handle a request, you need either respond to it or close it. If you don't close it (e.g: res.end, res.send, ...) the connection remains open. Also all the memory allocated for that request stays around without being collected.

Agree with the point, but remember normal HTTP/1.1 /2 keep alive should close that connection in 15-30 seconds for all modern browsers. It will give rise to a DOS vulnerability as you point out.

Re: Web Developer Security Checklist

#44
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? Most database encryption is "transparent", meaning the applications won't even be aware that their database is encrypted. Here is an example: https://docs.microsoft.com/en-us/sql/relational-databases/se...

This can probably explain more succinctly than I can.

https://aws.amazon.com/about-aws/whats-new/2015/12/amazon-au...

Re: Web Developer Security Checklist

#49
post #47
post #40

Earlier quoted context omitted.

Why lol? Not being a douche - I'm genuinely curious why that is a laughable suggestion.

Cloudflare MITMs your secure connections. If you get the cheaper Cloudflare options, it's really insecure.

Yes it does that and that will rule it out for some apps.

An option for many sites is to configure CloudFlare in pass-through mode (no MITM) and then just switch it on when you are being DOS'd.

Re: Web Developer Security Checklist

#50
post #47
post #40

Earlier quoted context omitted.

Why lol? Not being a douche - I'm genuinely curious why that is a laughable suggestion.

Cloudflare MITMs your secure connections. If you get the cheaper Cloudflare options, it's really insecure.

We offer free origin certificates on any plan level (yes, including FREE). It's not 'really insecure' and you seem to imply that encryption costs more with Cloudflare. That's not true.

https://blog.cloudflare.com/cloudflare-ca-encryption-origin/

Post reply on HN