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

151–160 of 249 posts

Re: Web Developer Security Checklist

#151

Post by [deleted] »

adamzochowski wrote: post #150
john61 wrote: post #133

Earlier quoted context omitted.

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

I am not the original poster, but some queries can't be moved to stored procedures (depends on SQL software and library abilities). For example: IN clauses can get tricky if prepared statements don't support arrays / lists of columns. Adhoc queries get tricky where user could specify a parameter or not. This answer is more about stored procedures than prepared statements.

[deleted]

Re: Web Developer Security Checklist

#152

Post by ams6110 »

spydum wrote: post #119

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.

I got downvoted in another reply, but "security by checklist" was one of the biggest complaints that SANS and other security firms had about enterprise and government IT security policies.

Not that it's a bad checklist, but most "web developers" will not have the background to understand and implement all of these things properly, even if they think they do. Security is not a checklist -- "OK, all boxes ticked, we're done" -- it is also an ongoing, reactive and proactive set of processes and constantly re-verifying that everything you think is so, is actually so. And if you rely on "web developers" to get all of this right you will at some point be disappointed.

Re: Web Developer Security Checklist

#153

Post by Avalyst »

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.

Re: Web Developer Security Checklist

#154

Post by FooBarWidget »

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…

> 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 agree with you, but I don't think that's what the author meant. Nowadays, when most people talk about "prepared statements" and "stored procedures", they are just conflating those things with escaping. I think they're trying to say, use something with an API that prevents injection bugs, rather than actually use database prepared statements.

I find that 9 out of 10 times, when people talk about "prepared statements" they are referring to something like the PHP bind_param thing (https://www.w3schools.com/php/php_mysql_prepared_statements....), rather than this sort of stuff: https://www.postgresql.org/docs/9.3/static/sql-prepare.html

Re: Web Developer Security Checklist

#155

Post by ad-hominem »

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 long as they get loaded. If you are using a tool to manage deployment, you probably just need a step to verify on deploy the files / lines containing keys exist.

I can't think of a widely-used programming language that doesn't support environment variables, though support may be less than exemplary in your language of choice. In ruby land, I use https://github.com/bkeepers/dotenv

Re: Web Developer Security Checklist

#156

Post by aeronautic »

adamzochowski wrote: post #150
john61 wrote: post #133

Earlier quoted context omitted.

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

I am not the original poster, but some queries can't be moved to stored procedures (depends on SQL software and library abilities). For example: IN clauses can get tricky if prepared statements don't support arrays / lists of columns. Adhoc queries get tricky where user could specify a parameter or not. This answer is more about stored procedures than prepared statements.

That is right. The key point is to reduce exposure to SQL injection by not formatting queries. Prepared statements help solve a whole class of bugs at a lower level.

Re: Web Developer Security Checklist

#157

Post by eggbrain »

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 think the idea is mainly that you separate your config from your code (https://12factor.net/config).

The main security benefits I could see would be:

- By having different config files (different files holding all your ENV variables), you could allow different levels of access. Imagine a junior developer only getting a staging api key vs getting the production api key for S3, for example. With hardcoded ENV variables, you'd probably put the highest level key possible, which would be something like "superuser" access.

- By separating out your ENV variables from your code, you make it more difficult for your entire app to be compromised than if they were bundled together. So if your Github repo got hacked, you aren't worrying about making sure everything else isn't hacked too as well.

In the end though, it's turtles all the way down. You still need your ENV variables to be exposed at some point, so those will inevitably be in some file that lists everything.

My question with ENV files is -- how are people sharing them? Over Slack? Through dropbox? On a USB drive? I feel like you may want some sort of permissions-based-access to them, but have never quite seen a service that does this.

Re: Web Developer Security Checklist

#158

Post by FooBarWidget »

pjungwir wrote: post #51
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 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.

Re: Web Developer Security Checklist

#159

Post by aeronautic »

ams6110 wrote: post #152
spydum wrote: post #119

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.

I got downvoted in another reply, but "security by checklist" was one of the biggest complaints that SANS and other security firms had about enterprise and government IT security policies. Not that it's a bad checklist, but most "web developers" will not have the background to understand and implement all of these things properly, even if they think they do. Security is not a checklist -- "OK, all boxes ticked, we're…

I think we can all agree that developers can get better educated about security and can participate building security into the product from the very start. It is hard to engineer security in via a sec-team at a later stage. Education is the key.

Re: Web Developer Security Checklist

#160

Post by ams6110 »

FooBarWidget wrote: post #154
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…

> 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 agree with you, but I don't think that's what the author meant. Nowadays, when most people talk about "prepared statements" and "stored procedures", they are just conflating those things with…

History has many examples of "safe escaping" that didn't turn out to be so safe after all.

I'd rather use proper prepared statements than rely on string escaping.

Post reply on HN