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

181–190 of 249 posts

Re: Web Developer Security Checklist

#181

Post by cookiecaper »

xupybd wrote: post #15
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…

Totally with you on the DB encryption but I'm not sure about your comments on prepared statements >That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries. I've always found using only prepared statements is feasible and justifiable. What is about using…

Most (good) ORMs/drivers will be transparently using prepared statements anyway. It explicitly informs the DB "this is unsafe user input" instead of trying to approximate that message with escapes.

Re: Web Developer Security Checklist

#182

Post by jdc0589 »

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.

Yes, and no. Most block storage services provided by cloud hosts shard data across tons of physical media.

Some of them (e.g. Google Cloud) encrypt everything at rest by default too.

Re: Web Developer Security Checklist

#183

Post by eropple »

thatwebdude wrote: post #171
swsieber wrote: post #124

Earlier quoted context omitted.

It does seem like emails are a good fit for encryption. I can't see wanting to do anything more than simple equality checks.

I could see a use case to see which emails are from what TLD. For instance, all @gmail, all @yahoo, all @aol. Maybe you want to do the cool "hey we noticed your email on haveibeenpwnd, you should change you password here just in case". In which case, anything other than plain text could prevent that from happening. Hashing an email in that sense gets much more difficult, no?

If you have enough emails that you can't SELECT * FROM users and do that query in memory, you're probably in a spot where you should not be picking security advice from a blog like this.

(That's not a negative as to this blog, it's really good and I've recommended it to multiple clients already, but that level of acumen should already be assumed at that scale. If you don't have it, this blog post is insufficient.)

Re: Web Developer Security Checklist

#184

Post by dom0 »

bradleyjg wrote: post #162
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.

I'm fairly certain, and I believe most experts of the field are too, that "general purpose" homomorphic encryption will never happen.

Re: Web Developer Security Checklist

#185

Post by cookiecaper »

ams6110 wrote: post #143
sho wrote: post #31

Earlier quoted context omitted.

My apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.

Nothing wrong with stored procedures. Like anything else, they might not be right for every application.

The image of sprocs continues to suffer from "store all application logic in the database" syndrome, which was all the rage in the early and mid 00s before APIs started to take off. There's nothing necessarily inherently wrong with that approach, but most people have gravitated away from it. DBA/dev split probably had something to do with it.

Re: Web Developer Security Checklist

#186

Post by eropple »

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…

> Curious: Is there a widely-used off the shelf solution/pattern for this?

Credstash, Sneaker, etc. are fine in AWS.

> wouldn't your app need to authenticate with that service with... a hardcoded secret?

Trusted third parties can provision your initialization secret, i.e. AWS IAM instance profiles providing role credentials automatically to EC2 instances. (Set up a policy that can read secret keys for specific encryption contexts and be done with it.)

Re: Web Developer Security Checklist

#187

Post by aeronautic »

tptacek wrote: post #173

There are 168 comments on this thread all earnestly discussing what is pretty clearly a marketing document written by someone without a firm grip on most of the bullets they've written. Is there that much of a need for another "security checklist", that we'll dive in this deep on a really bad one? Seriously asking! Finally: if you're worried about "APTification" or whatever it is this company is talking about, and yo…

As the author, I should clarify that I am a developer - full time and have been for years. If my english seems to imply a lack of depth of understanding - I'm sorry.

The purpose of the checklist is to get people thinking about items they may have forgotten to address during their dev. In the push to ship new products quickly, that happens all too often.

I agree with you that there are many more important and basic things to do first when securing your app - than worrying about APTs. I did not think the checklist gave that impression?

Re: Web Developer Security Checklist

#188

Post by eropple »

ams6110 wrote: post #141
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…

Sure, classic chicken and egg problem. At some point you need an unencrypted secret.

A better way to phrase it is that at some point you need trust. AWS IAM instance profiles are a great example of this.

Re: Web Developer Security Checklist

#189

Post by creepydata »

sho wrote: post #32
aeronautic wrote: post #21

Earlier quoted context omitted.

No much at all.

For RoR many of the app-level points are - CSRF, SQL escaping, bcrypt by default, etc. That's a big reason to use such a framework in the first place.

Yeah, what kind of shitty frameworks is this person using if the answer to this question is "not much at all?"

Re: Web Developer Security Checklist

#190

Post by creepydata »

aeronautic wrote: post #180
creepydata wrote: post #178

Earlier quoted context omitted.

How is something like "Use CSP without allowing unsafe-* backdoors" in any way educational? If I'm a newbie web developer, even coming over from embedded systems, how do I know what CSP is? What do I use CSP for? How do I start with CSP? What do I do to configure CSP? What does CSP even stand for? I don't know, it wasn't even defined! Basically, this is a useless listicle. If you know anything about web security you…

Try this to get you started: https://www.troyhunt.com/understanding-csp-the-video-tutoria...

I don't need to get started and I don't need that link; I, personally, know how to develop secure webapps. I am criticizing your listicle for being useless because it is. Your "educational" resource is not educational for anyone.
Post reply on HN