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

201–210 of 249 posts

Re: Web Developer Security Checklist

#201

Post by aeronautic »

eropple wrote: post #198
aeronautic wrote: post #193

Earlier quoted context omitted.

I agree with you, but I understand his wish though. Security sometimes is just hard and it is unrealistic to hope that all developers, everywhere, all the time will get it right. The more the platform can do, the better.

I understand it too, but it's, to be honest, horseshit. Well-meaning horseshit, but horseshit despite it. Security is hard. It is irreducibly hard when you add the constraint that arbitrary do-whatever code and applications must be supported. Having your platform do things is great-- to make you faster . You still have to understand what it's doing because it's very easy to step outside the guarantees of that platfor…

No argument on that (except the horseshit ;-)

Re: Web Developer Security Checklist

#202

Post by e12e »

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?

It also makes it easier to move servers, recycle hard drives etc - safe in the knowledge that the whole disk was encrypted - without worrying about where the used disk ends up.

The only real alternative is to manage your own servers in house and degauss/drill through old drives. And this might be more of a hassle (at scale) with ssds.

Consider a faulty disk that is replaced. It might be possible to recover data by using advanced techniques - but might not be possible to remotely wipe it. Now you have to hope your provider manages to safely dispose of the drive.

Re: Web Developer Security Checklist

#203

Post by sroussey »

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…

Personally, I'd rather have people have their little apps with too much security than major apps with too little.

Also, having people trained in good practices would make hiring easier.

Re: Web Developer Security Checklist

#204

Post by sroussey »

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…

Database encryption at rest is a normal practice for PII data.

MySQL example: https://www.mysql.com/products/enterprise/tde.html

Percona article: https://www.percona.com/blog/2016/04/08/mysql-data-at-rest-e...

Re: Web Developer Security Checklist

#205

Post by Programmatic »

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…

I looked at the two linked pieces of documentation, and to my naive eyes they look like they perform the same task:

PHP: "Bound parameters minimize bandwidth to the server as you need send only the parameters each time, and not the whole query", meaning that the statement is prepared server-side and parameters are sent separately.

Postgres: "A prepared statement is a server-side object that can be used to optimize performance. When the PREPARE statement is executed, the specified statement is parsed, analyzed, and rewritten. When an EXECUTE command is subsequently issued, the prepared statement is planned and executed.... Prepared statements only last for the duration of the current database session. When the session ends, the prepared statement is forgotten, so it must be recreated before being used again."

Is there a difference between the two, and could you elaborate?

Re: Web Developer Security Checklist

#206

Post by Programmatic »

nulagrithom wrote: post #161
Avalyst wrote: post #153

Earlier quoted context omitted.

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

Disk encryption also prevents disposal issues from affecting you, which is a separate problem than physical access.

Re: Web Developer Security Checklist

#207

Post by sroussey »

drostie wrote: post #166
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?

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…

Until you deal with important data, like records indicating money in a bank account. Then it's more like "tough shit you can't just slap an ORM on the direct table data".

Most people don't deal with important records though, and generally not people here (though a shout out to people from Stripe and other payments companies!). So I would t recommend stored procedures for this cloud either.

I do recommend prepared statements, but they do have a cost since it is two network calls for one query instead of one. Totally worth it too.

Re: Web Developer Security Checklist

#208

Post by cookiecaper »

e12e wrote: post #195
cookiecaper wrote: post #185

Earlier quoted context omitted.

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.

I'd venture the real reason is many devs know too little of normalisation, data structure and structured data. Somehow a mess of structures/data objects paired with functions working on these objects - with only ad-hoc ways of enforcing foreign key relationships are seen as "easier", and "better for maintenance" than leveraging an actual (relational) database management system. Sure it's more fun writing functions th…

If document databases like MongoDB have taught us anything, it's that developers hate any sort of data organization, which is ridiculous and ironic since most of their day-to-day is about manipulating data. Mongo is popular because it allows the developer to stuff a value without thinking about its structure and role, generally leading to utter disaster further down the road.

I do think the biggest problem is that it brought everything into the DBA's turf, and made it too difficult for devs to do their jobs without meddling. As long as there is a dev/DBA organizational dichotomy, there will have to be a structural dichotomy in the software (cf. Conway's Law).

Re: Web Developer Security Checklist

#210

Post by e12e »

cookiecaper wrote: post #208
e12e wrote: post #195

Earlier quoted context omitted.

I'd venture the real reason is many devs know too little of normalisation, data structure and structured data. Somehow a mess of structures/data objects paired with functions working on these objects - with only ad-hoc ways of enforcing foreign key relationships are seen as "easier", and "better for maintenance" than leveraging an actual (relational) database management system. Sure it's more fun writing functions th…

If document databases like MongoDB have taught us anything, it's that developers hate any sort of data organization, which is ridiculous and ironic since most of their day-to-day is about manipulating data. Mongo is popular because it allows the developer to stuff a value without thinking about its structure and role, generally leading to utter disaster further down the road. I do think the biggest problem is that it…

I wonder how many developers would consider using the filesystem as a document store bad practice, but at the same time be happy using mongodb.

It's odd that with the rise of solid, free rdbms' like postgresql (and the current generation of mysql forks) - the general reaction among developers hasn't been to realize that 99% of systems are/should be data-first/data centric - but rather a stubborn struggle to pretend their language supports transaction-guaranteed persisted runtime/memory -- without actually using a real object database like zoodb (for python) or gemstone.

Post reply on HN