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

171–180 of 249 posts

Re: Web Developer Security Checklist

#171

Post by thatwebdude »

swsieber wrote: post #124
aeronautic wrote: post #98

Earlier quoted context omitted.

No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive. And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.

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?

Re: Web Developer Security Checklist

#173

Post by tptacek »

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 you're deploying in AWS or GCP, do what Ryan's team at Slack did and get auditd monitoring on all your servers, and perhaps get osquery instrumentation set up as well. Attack detection systems like the product this post sells are pretty far down the list of things you should be considering.

Re: Web Developer Security Checklist

#174

Post by aianus »

aeronautic wrote: post #49
Animats wrote: post #47

Earlier quoted context omitted.

Cloudflare MITMs your secure connections. If you get the cheaper Cloudflare options, it's really insecure.

Yes it does that and that will rule it out for some apps. An option for many sites is to configure CloudFlare in pass-through mode (no MITM) and then just switch it on when you are being DOS'd.

But then the attackers know your origin IP from before you turned on MITM and can just DDOS it directly.

Re: Web Developer Security Checklist

#175

Post by thatwebdude »

SadWebDeveloper wrote: post #167
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.

Is 404 sufficient?

Re: Web Developer Security Checklist

#176

Post by aeronautic »

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.

Re: Web Developer Security Checklist

#177

Post by pyre »

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.

Right, but the existence of homomorphic encryption isn't something should prompt developers to start implementing it as a "best practice" now.

(Even then, my understanding of homomorphic encryption is that it would not be great for generalized queries against the data like you would expect in a database with SQL)

Re: Web Developer Security Checklist

#178

Post by creepydata »

aeronautic wrote: post #159
ams6110 wrote: post #152

Earlier quoted context omitted.

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.

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 get nothing from it and if you don't know anything about web security you still get nothing from it.

Re: Web Developer Security Checklist

#180

Post by aeronautic »

creepydata wrote: post #178
aeronautic wrote: post #159

Earlier quoted context omitted.

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.

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

Post reply on HN