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

161–170 of 249 posts

Re: Web Developer Security Checklist

#161

Post by nulagrithom »

Avalyst wrote: post #153
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…

At rest basically means on disk. People might not think about this but AWS actually has a physical disk somewhere which someone could yank from the data center and read from. Not that likely but also not hard to protect yourself from.

If someone is yanking and reading disks at AWS then the game was over a long time ago. Physical access always wins.

IMO, if you're on AWS (or similar) then at rest encryption is a wholly unnecessary expense, unless you need to tick some kind of regulatory checkbox. I can see it for smaller on premise racks to prevent a "smash and grab" problem, but in a secure datacenter? Nah...

Re: Web Developer Security Checklist

#162

Post by bradleyjg »

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?"

There is an area of active research called homomorphic encryption that would allow for operations against encrypted data. Right now it is too slow to be practical, but maybe in the future.

Re: Web Developer Security Checklist

#163

Post by pjungwir »

brlewis wrote: post #109
pjungwir wrote: post #51

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…

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?

No, and I've set it up many times. It's just . . . whenever I talk to people about this I get the impression they think it secures them against more. Non-technical people especially (but not just them) worry about someone "hacking into the system". Full-disk encryption is almost more like physical security than digital security.

Re: Web Developer Security Checklist

#164

Post by pjungwir »

FooBarWidget wrote: post #158
pjungwir wrote: post #51

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…

We use disk encryption to protect against a specific attack that had occurred in the past: the attacker hacks the hosting provider's admin panel and uses it to reboot our server into a rescue system, in which he has access the raw disk.

Good example! So many vulnerabilities come from a lack of imagination. :-)

Re: Web Developer Security Checklist

#165

Post by DamonHD »

atemerev wrote: post #128
DamonHD wrote: post #120

Earlier quoted context omitted.

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 ju…

...and this is why Gerard 't Hooft, the famed theoretical physicist, can't register with his real name nearly anywhere. :( https://en.wikipedia.org/wiki/Gerard_%27t_Hooft

That sounds like BAD validation that needs fixing, not an excuse not to do any.

Some US sites still won't let me in because (a) they insist that I must have a middle name or (b) screw up the hyphen in my surname.

Many sites and payroll systems assume that everyone has a surname. Never mind its character set and ordering.

Even if you don't make these assumptions you don't need to accept a binary gzipped GB of zeros or worse in a name input field.

Re: Web Developer Security Checklist

#166

Post by drostie »

john61 wrote: post #133
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…

>> Fully prevent SQL injection by only using SQL prepared statements and stored procedures > That is an extraordinarily inefficient and costly way to develop. Why is this inefficient? Can you elaborate?

As mentioned beneath, the comment was secretly fixated on the 'stored procedures' side and not the 'prepared statements' side. Stored procedures have many costs associated to them; for example, they don't get version-controlled by default and they don't lend themselves easily to a development/production schism; both of these need to be solved by writing out some sort of database-synchronizer-script which will handle fallover. In addition usually you cannot issue breaking changes to an SPROC without scheduled downtime, so you have to intentionally have a flow of "create new SPROC, make code use the new SPROC, deploy across the codebase and audit for the old SPROC's use, finally remember to drop the old SPROC so that old code doesn't get recycled by someone who is looking for the first thing that does what they want." Compare that to just "commit a new patch, then upgrade servers as soon as possible".

Re: Web Developer Security Checklist

#167

Post by SadWebDeveloper »

adakbar wrote: post #142

Is it good to redirect to https when user hit API with http? I have heard somewhere doing so is bad

Nop.. it isn't good, secure endpoints for API's shouldn't be exposed in plain, an error should be raised when a developer/app tries to contact via HTTP rather than HTTPs.

Re: Web Developer Security Checklist

#168

Post by creepydata »

aeronautic wrote: post #52
pjungwir wrote: post #51

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…

Psst, I really hate to break it to you but you are "stealing" and "hacking" your users email addresses ever time you send them an email!

https://www.troyhunt.com/im-sorry-but-your-email-address-is-...

Re: Web Developer Security Checklist

#169

Post by eggbrain »

My biggest worry with this checklist is that while it helps already security-minded people and web developer professionals remember what they should already be doing, it doesn't really help security novices (who may search for something like this) make their app more secure. Why?

1. The checklist tells me what I need to do, but not how to do it right.

I could imagine many security novices reading one of these items, implementing the first solution they find on StackOverflow, and checking it off in a "fixed it, boss" kind of manner. That may lead them to thinking their app is more secure than they should, and is then a detriment to the security of their app.

2. The checklist doesn't really help me decide in what order to do things, and what perceived increase in security I'll receive

Storing sensitive data in the database using bcrypt is pretty easy to implement (many times baked into web frameworks), and provides a good amount of security for the time it takes. Compare that to something like implementing CSP however, which may involve moving a ton of files around your app, adding nonces/hashes, etc, and it gets me an A+ on secureheaders.io, but I'm not sure if all the pain was worth it for my basic application.

3. The checklist makes things way harder for a developer to think about.

Anyone wanting to build a web app looking at this list would probably be too overloaded with information to want to implement much of this, when in reality, they could start off with something like Heroku where they just push it up and it works, and many of the security concerns have been taken care of for them.

Re: Web Developer Security Checklist

#170

Post by ryandrake »

ad-hominem wrote: post #155
ryandrake wrote: post #138

> Store and distribute secrets using a key store designed for the purpose. Don’t hard code in your applications. Curious: Is there a widely-used off the shelf solution/pattern for this? Or a "idiot's guide to writing one"? It's always seemed to me like super bad practice to hard-code a (for example) AWS secret into your app. However if you set up a basic web service to deliver the AWS secret to the app, wouldn't your…

I always use environment variables, you can just use ENV['AWS_S3_KEY'] or whatever in your application code. Keep the keys in your local environment, and add separate sets of keys to the staging / production environments. These files probably live in your project (.env or similar) in development but are gitignored. On production, they can be in your web-server or application configuration wherever appropriate, as lon…

Not sure how storing the secret in the user's environment helps. At the end of the day, you're still distributing a secret to an untrusted end user.
Post reply on HN