Live data from Hacker News

Web Developer Security Checklist

simplesecurity.sensedeep.com

51–60 of 249 posts

Re: Web Developer Security Checklist

#51
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…

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physically pulling the drive and walking off with it.

Also this business of two layers of encryption: yep, anything encrypted can't be indexed or searched (basically). At best you can encrypt the query input too and compare for strict equality---sort of like hashing passwords. (Is that what he means?) I've never seen anyone hash email addresses though. And encrypting billing details . . . okay, I guess, although if the app has the decryption key, then what security are you really adding?

Re: Web Developer Security Checklist

#52
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…

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physicall…

If the hacker gets access to the database due to a network config error, then they will be able to query the database, but only get records with some sensitive fields encrypted.

Given the number of email addresses that have been hacked and stolen (3.75 billion in Troy Hunt's haveibeenpwned alone), I believe doing one little extra bit of encryption on email addresses is worthwhile. We push that into our ORM layer and can easily flag any field in the database to be encrypted.

On very, very high volume accessed tables, you may not want to do that. But for user logon details -- for us it was a no brainer.

Re: Web Developer Security Checklist

#53
post #47

Earlier quoted context omitted.

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/

Your data is in the clear within Cloudflare, and may even be in the clear between Cloudflare and the real host if you choose that option. You're trusting Cloudflare's security and Cloudflare's internal certificate authority. Hundreds or thousands of sites would be compromised if Cloudflare had a security breach. Like the one they had three months ago.[1]

[1] https://techcrunch.com/2017/02/23/major-cloudflare-bug-leake...

Re: Web Developer Security Checklist

#54

Earlier quoted context omitted.

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physicall…

If the hacker gets access to the database due to a network config error, then they will be able to query the database, but only get records with some sensitive fields encrypted. Given the number of email addresses that have been hacked and stolen (3.75 billion in Troy Hunt's haveibeenpwned alone), I believe doing one little extra bit of encryption on email addresses is worthwhile. We push that into our ORM layer and…

Wait, so you encrypt the user's email before it's inserted into the table?

Are you using a different field for 'username' on logins, or do you have to jump through some hoops to find an encrypted email to do a login check against the pw hash?

Re: Web Developer Security Checklist

#55
post #53

Earlier quoted context omitted.

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/

Your data is in the clear within Cloudflare, and may even be in the clear between Cloudflare and the real host if you choose that option. You're trusting Cloudflare's security and Cloudflare's internal certificate authority. Hundreds or thousands of sites would be compromised if Cloudflare had a security breach. Like the one they had three months ago.[1] [1] https://techcrunch.com/2017/02/23/major-cloudflare-bug-leak…

Data is only 'in the clear' inside a machine. All machine to machine communication in Cloudflare is encrypted with mutually authenticated TLS. If a user chooses to not encrypt the back haul from Cloudflare to their origin then, sure, that's not encrypted, but we offer free certificates for origin machines so there's no reason to use that option. If you don't like Cloudflare's Origin CA then use Let's Encrypt on the origin server.

Re: Web Developer Security Checklist

#57

Apparenlty written by somebody who isn't responsible for the actual web development themselves, just upfixed web devs work for enterprise pen testing.

Sorry, not true. Spent many years doing full stack web dev and security. Please offer some constructive criticism - gladly received.

Re: Web Developer Security Checklist

#59
post #34

Earlier quoted context omitted.

Good point. I did say: "This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application." But I'll try to make that clearer. I'm limited by space and peoples attention span. Having links to implementation notes will address your concern I think.

> I'm limited by space and peoples attention span Might I suggest a simple "tag" for each suggestion indicating the appropriate market for that point. Eg good - your basic SAAS/casual web app. Great - apps dealing with moderately sensitive data. Extreme - you're building a bank, seeking PCI compliance, storing medical data, etc. You could break it out at the top, and then it doesn't take much space in the body of the…

A tag like this would be a great idea. I'm playing around with a very basic casual web app that will have no sensitive data besides a hashed username/password. If someone wants to hack the database and give themselves nearly unlimited in a game with no leaderboards and share it with their friends I could care less (I'd actually be happy because that means someone actually cares about the app). I'll be using a BaaS to store data so I don't think I have to worry about things like sql injection but I have no experience with web work so correct me if I'm wrong.

Re: Web Developer Security Checklist

#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.

Post reply on HN