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

191–200 of 249 posts

Re: Web Developer Security Checklist

#191

Post by eropple »

FLUX-YOU wrote: post #135
aeronautic wrote: post #7

Earlier quoted context omitted.

Do both. I'm a big believer in having dev learn and own a part of the security process. You learn an enormous amount by hacking yourself. But you are right, you definitely need other eyes to pen test as well.

>Do both. I'm a big believer in having dev learn and own a part of the security process. Devs already do enough, take some bloody ownership of security outside and inside of code. When devs start having to whiteboard security issues in interviews, then you can make us responsible for it because we'll appropriately charge you for being decent at two things instead of one.

This is...shortsighted. Security is part of your development work. It always has been, always will be. You need to understand application and server-level security--the former is always your responsibility and while you may have specialists for the latter they do not replace you understanding the fundamentals of it. The server is part of your "stack", even if the "full-stack" people want you to believe it ends at the language runtime.

If you are a web developer and in your interviews you aren't demonstrating that you can think in a security-conscious way, your interviewers need to reflect.

Re: Web Developer Security Checklist

#192

Post by eropple »

Kiro wrote: post #46

When do we get a SaaS which just comes with all this built-in? I want to pick a framework and let the service add all these things, including automatic updates.

What you want, and what is effective and feasible, are at odds. Trying to build a framework for this to work in the general case will--not may, will--result in something that doesn't work in that general case for anybody.

You can't framework away security. Parts can be abstracted, but that abstraction is for ease-of-use, not correctness; you need to understand what's going on and why. It's your job to. (Or pay someone else to. But we're expensive.)

Re: Web Developer Security Checklist

#193

Post by aeronautic »

eropple wrote: post #192
Kiro wrote: post #46

When do we get a SaaS which just comes with all this built-in? I want to pick a framework and let the service add all these things, including automatic updates.

What you want, and what is effective and feasible, are at odds. Trying to build a framework for this to work in the general case will--not may, will--result in something that doesn't work in that general case for anybody. You can't framework away security . Parts can be abstracted, but that abstraction is for ease-of-use, not correctness; you need to understand what's going on and why. It's your job to. (Or pay someo…

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.

Re: Web Developer Security Checklist

#194

Post by wkd »

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…

> Encrypt all data at rest in the database

This is funny, I've actually inherited a project where the original developer had this idea, he used the same function to encrypt everything: even the news posts available on the front page were encrypted. The passwords were using the same encryption functions and needless to say not using a one way hash so fully decryptable...

Re: Web Developer Security Checklist

#195

Post by e12e »

cookiecaper wrote: post #185
ams6110 wrote: post #143

Earlier quoted context omitted.

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.

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 than thinking about data integrity - but the vast number of applications are concerned with managing structured information: from scenes in a game that could be interlocking state-machines to the more mundane user/message pairs or similar.

Design is eschewed for prototyping - but then the prototype is kept as the production system, rather than as a basis for design of a better (simpler) system.

Re: Web Developer Security Checklist

#196

Post by eggbrain »

aeronautic wrote: post #176
eggbrain wrote: post #169

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

Thanks for your well structured comments. The purpose of the checklist was to get people to think. It is really hard to do much more without going very long. A number of people have suggested that I link implementation background off each item. I think that can work and layer the info as well.

I know your pain -- things like this get long fast, and it's hard to include everything all at once without going on forever. I would definitely appreciate implementing some background off of each item!

Another thing that might help is knowing about services or open source solutions that can bundle a lot of the checklist together. Heroku might be a paid one, for example, but there might be things like ansible scripts out there that do a lot of this from security professionals, I'd love to know how to be able to package a lot of these checklist items together more easier.

Re: Web Developer Security Checklist

#197

Post by aeronautic »

wkd wrote: post #194
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…

> Encrypt all data at rest in the database This is funny, I've actually inherited a project where the original developer had this idea, he used the same function to encrypt everything: even the news posts available on the front page were encrypted. The passwords were using the same encryption functions and needless to say not using a one way hash so fully decryptable...

Sorry that is not quite what was intended. I've revised the text to say:

If your database supports low cost encryption at rest (like AWS Aurora), then enable that to secure data on disk. Make sure all backups are stored encrypted as well.

i.e. this kind of encryption costs very, very little and give you physical security if you need it.

Re: Web Developer Security Checklist

#198

Post by eropple »

aeronautic wrote: post #193
eropple wrote: post #192

Earlier quoted context omitted.

What you want, and what is effective and feasible, are at odds. Trying to build a framework for this to work in the general case will--not may, will--result in something that doesn't work in that general case for anybody. You can't framework away security . Parts can be abstracted, but that abstraction is for ease-of-use, not correctness; you need to understand what's going on and why. It's your job to. (Or pay someo…

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 platform and suddenly no longer benefit from those security features. Sometimes you might even have to do that for business reasons. And then you must know how to safely compensate for it.

It's a rare web developer who isn't safeguarding somebody else's personal information. (Yes, even just name + email. Don't make it easier for other people to be phished.) The onus is on us as a development community to take that seriously and to treat the security of our code and our systems with the caution it mandates.

Re: Web Developer Security Checklist

#199

Post by aeronautic »

eggbrain wrote: post #196
aeronautic wrote: post #176

Earlier quoted context omitted.

Thanks for your well structured comments. The purpose of the checklist was to get people to think. It is really hard to do much more without going very long. A number of people have suggested that I link implementation background off each item. I think that can work and layer the info as well.

I know your pain -- things like this get long fast, and it's hard to include everything all at once without going on forever. I would definitely appreciate implementing some background off of each item! Another thing that might help is knowing about services or open source solutions that can bundle a lot of the checklist together. Heroku might be a paid one, for example, but there might be things like ansible scripts…

Coding is easy, writing is just darn hard!!

Thanks for the ideas. I'll check those out.

Re: Web Developer Security Checklist

#200

Post by daxorid »

jgrahamc wrote: post #55
Animats wrote: post #53

Earlier quoted context omitted.

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

Even so, there's nothing preventing a LE or court order from compromising the confidentiality of your customers, no matter how hard you work on minimizing the scope of your cleartext domains.

I know that you, Prince, rdl, and others are serious about security and privacy, but let's be honest here: If the Feds come a-knocking, you will comply.

It's not that we don't trust you or your competence. You're just not immune to the jackboot threat model.

Post reply on HN