
Web Developer Security Checklist - aeronautic
https://simplesecurity.sensedeep.com/web-developer-security-checklist-f2e4f43c9c56
======
sho
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 secondary encryption for data identifying users and any sensitive data
> like access tokens, email addresses or billing details

So _two_ layers of encryption!? Again, how is one supposed to look up an
access token or email address if it is encrypted? And it strikes me that if
you don't trust the first level of encryption, the solution is to fix that,
not add _another_ one.

> Fully prevent SQL injection by only using SQL prepared statements and stored
> procedures

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 could go on. The costs of implementing these recommendations would be
staggering for the questionable benefits they would provide. It is absolutely
possible to have excellent security without implementing any of these ideas,
and I don't think they're helpful at all - and certainly not "simple".

~~~
pjungwir
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 physically pulling the drive and walking off
with it.

Also this business of two layers of encryption: yep, anything encrypted can't
be indexed or searched (basically). At best you can encrypt the query input
too and compare for strict equality---sort of like hashing passwords. (Is that
what he means?) I've never seen anyone hash email addresses though. And
encrypting billing details . . . okay, I guess, although if the app has the
decryption key, then what security are you really adding?

~~~
aeronautic
If the hacker gets access to the database due to a network config error, then
they will be able to query the database, but only get records with some
sensitive fields encrypted.

Given the number of email addresses that have been hacked and stolen (3.75
billion in Troy Hunt's haveibeenpwned alone), I believe doing one little extra
bit of encryption on email addresses is worthwhile. We push that into our ORM
layer and can easily flag any field in the database to be encrypted.

On very, very high volume accessed tables, you may not want to do that. But
for user logon details -- for us it was a no brainer.

~~~
stephenr
Wait, so you encrypt the user's email before it's inserted into the table?

Are you using a different field for 'username' on logins, or do you have to
jump through some hoops to find an encrypted email to do a login check against
the pw hash?

~~~
k__
Can't you encrypt the entered email and search with that?

~~~
aeronautic
Password hashes are handled separately using bcrypt - another story.

For the User.email field, we crypt/decrypt in the ORM/DB layer. So we search
with the encrypted value that is stored in the db. App code provides plain-
text email, ORM encrypts and searches with that value. Symmetric encryption of
short strings is pretty fast and this is not a high volume API.

We use rate limiting on the API to protect against DOS on this API.

~~~
arjie
If it's symmetric, then doesn't an app vulnerability make it possible for you
to leak your key? Then the app also contains access credentials to the DB, so
vulnerabilities in the app will still lead to real access to the DB, right?

~~~
aeronautic
Yes, we're not protecting against the app being attacked, the key being jacked
and then the attacker getting access to the db. Rather, we're protecting the
database against being accessed directly. That could happen due to an error in
configuring network access to the database or another service could be
compromised that has access to the same database -- as has happened to many
mongo databases over this year.

~~~
stephenr
So your solution to fixing a basic ops problem 'software package A was exposed
to the internet with(out|effectively no) auth' is: encrypt shit in an ORM
layer and destroy your ability to do anything beyond absolute string
comparison queries.

No thanks.

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

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

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

~~~
eropple
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.)

------
smoyer
OWASP has published a release candidate of the OWASP "top-ten" available as a
PDF at
[https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2...](https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf).
They also support the creation and maintenance of quite a few OSS tools to
help secure systems.

To those who are claiming some of these steps are too onerous or would cause
performance issues: Are you sure? For an individual system, maybe some of
these checkboxes are indeed overkill. Or perhaps your system isn't as secure
as you believe? To be fair, there are systems that don't require as much
security because the data simply doesn't matter - if they systems contain
email address / password hash combinations, they should still treated very
carefully.

I think the biggest mistake I've seen made time and time again is that teams
go the cheap route and put the database on an Internet connected machine.
Don't build a whole architecture until you've got customers to support it but
don't be quite that cheap at the beginning.

For systems that require higher than average security, I've been part of a
team that went to _MUCH_ further extremes.

~~~
hartleybrody
Can you elaborate a bit more detail around a MVP-style architecture where the
database isn't on the public internet?

I assume you're talking about something like a public facing load balancer
that connects into a private network where the web servers and database server
live, and you'd need a bastion host (or just the load balancer) to connect
into the private network and access any of the machines.

~~~
smoyer
Yes ... that's about the simplest form. If you want to get really fancy you
can use a further cloistered machine with hardware encryption and a key that's
only inserted when the machine is booted but that's pretty excessive. The main
thing is that you don't want your database server's port exposed to the
Internet and you don't want your database on your web servers (the most likely
part of your infrastructure to be compromised).

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

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

~~~
wglb
English is not the problem.

You are missing fundamentals like the Seven Deadly Sins of Web Security. Also
missing is ninja threat model.

These are the thing that will wipe you out.

------
strictfp
This list could just as well be called "List of security stuff I learned about
when making my product". Some of the stuff is just Draconian, certainly not
applicable for any arbitrary web developer.

~~~
viraptor
There are rarely any checklists applicable everywhere in the same way. Why not
treat it as: list of ideas to evaluate and prioritise/ignore into your own
checklist for future/current project? It's not like it's all invalid because
it's not fully applicable.

~~~
strictfp
No, I think it's valuable as a work log and bucket of ideas on how to improve
security. It's just how it's framed that irks me.

------
cyberferret
Hope the moderators edit the post title to include that this is a 'security'
checklist, and not just a 'steps I need to develop a simple website'
checklist. I am thinking quite a few people skipped past this article not
realising the intended audience.

~~~
michaelmior
Agreed. The original title of "Web Developer Security Checklist" is much
better.

------
eggbrain
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, implementing
the first solution they find on StackOverflow, and checking it off in a "fixed
it, boss" kind of manner. That may lead them to thinking their app is more
secure than they should, and is then a detriment to the security of their app.

2\. The checklist doesn't really help me decide in what order to do things,
and what perceived increase in security I'll receive

Storing sensitive data in the database using bcrypt is pretty easy to
implement (many times baked into web frameworks), and provides a good amount
of security for the time it takes. Compare that to something like implementing
CSP however, which may involve moving a ton of files around your app, adding
nonces/hashes, etc, and it gets me an A+ on secureheaders.io, but I'm not sure
if all the pain was worth it for my basic application.

3\. The checklist makes things way harder for a developer to think about.

Anyone wanting to build a web app looking at this list would probably be too
overloaded with information to want to implement much of this, when in
reality, they could start off with something like Heroku where they just push
it up and it works, and many of the security concerns have been taken care of
for them.

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

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

~~~
aeronautic
Coding is easy, writing is just darn hard!!

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

------
iamdave
"Hack yourself"

May I suggest the opposite, and say if you're going to pen test your
infrastructure, don't have the same people maintaining the infrastructure
trying to hack the infrastructure.

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

~~~
FLUX-YOU
>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.

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

~~~
FLUX-YOU
>Security is part of your development work

So is everything else, apparently: databases, algorithms, data structures,
operating systems, cloud infrastructure, front end design, business logic
features, etc., etc., etc. -- the list just keeps fucking growing and you
people are turning devs into skill black holes where they're never going to
master anything. All of it apparently matters at one point or another and
you're not a good developer if you're not prepared to be the best at
everything!

As a web developer, your security knowledge is rarely assessed and tested. If
you're not focusing on security 100% of the time, you're not going to be as
good as a professional and the bad guys.

You need people focused on security doing the security work. Having someone do
business features and security work at the same time is an indication you
don't take security seriously because you do not have dedicated people for it.
If Bob who's mostly front-end but some back-end says it's secure, I'm not
going to believe him. That's the same false confidence that companies parrot
to us when they say that "security is a priority", but they have XP machines
on their network still and code vulnerable to SQL injection in their code.
Don't tell me this doesn't exist because I woke up this morning and _read that
exact email_. You can't half-ass security and a line of business developer is
not a security professional.

This doesn't mean you get to be lazy and continue to concat SQL strings even
after someone has told you it's bad in a code review.

~~~
eropple
_> So is everything else, apparently_

Yes. Sorry (not snarky) that it sounds like you work in a lousy place, but if
your "security people" aren't cutting it, you are the line of defense for your
users. You need to understand this stuff to be able to do the right thing.
Being at least competent--and we're not talking A-plus or best-in-the-
business, we're talking a solid C-plus to B, able to consistently make things
better rather than leave them static or regress--in these things is your
responsibility when you take a job working on stuff that touches these fields,
because _somebody has to and you 're a somebody_. "Security people" (and I'm
not one, I'm a software developer--though, somehow, [this part is snarky] none
of databases, algorithms, operating systems, cloud infrastructure, front end
design, business logic features, _or_ application security are beyond me;
weird, that) are there to help you, not excuse you from your responsibilities.

There's a lot of stuff to understand! This is why you are paid the medium
bucks. Remove "not your job" from your vocabulary and you'll be better at not
just these things, but the things you think are your job, too. Because each
bit informs the rest.

~~~
FLUX-YOU
>Remove "not your job" from your vocabulary and you'll be better at not just
these things

No one else is removing that from their vocabulary. I don't see the incentive
for me to do that.

This is the problem. You haven't realized that everyone is saying "not my job"
and pushing it all onto developers.

~~~
eropple
_> I don't see the incentive for me to do that._

Oh, I don't know, to not be bad at what you do for a living so you can call
yourself a _professional_ without it being a farce?

I don't care what other people are doing and you shouldn't either. I care
about doing the right thing and building good systems that work for people
rather than expose them to risk and you should too--and that means
understanding the breadth of your _profession_. The people who are pushing
responsibilities onto you are the people that software is automating out of
existence and are of no account except that you get to feel good by "pushing
back" in ways that just make everything worse.

~~~
FLUX-YOU
>I don't care what other people are doing and you shouldn't either.

Until their decisions affect your work, and you don't get to say anything
about it. Because the people pushing around responsibilities are usually your
bosses or equals, so you can't really do anything about that. If you get to
work in a silo where you're responsible for everything and you understand
everyone and do it well, great, you're a master of the universe. You should be
a multi-millionaire by retirement at 45.

But most developers won't ever approach that level. Putting your best people
in the best slots is a practical approach for teams > 1\. And there's no
reason you should be mixing responsibilities and watering down everyone's
chance at becoming good at ~literally everything in development~

~~~
eropple
Let me restate, so you can catch it: I'm not saying _be good at everything_. I
am saying _be bad at nothing relevant to your work_.

Security is without exception and in all circumstances critically relevant to
web development. You cannot be an adequate web developer if you cannot look at
a system and break down its security impact and how to mitigate it. You can be
a bad one, but you can't be even an adequate one.

Less excuses, more practice. It's what you signed up for.

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

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

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

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

~~~
aeronautic
Try this to get you started:

[https://www.troyhunt.com/understanding-csp-the-video-
tutoria...](https://www.troyhunt.com/understanding-csp-the-video-tutorial-
edition/)

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

------
partycoder
A largely incomplete list. One of the most important items would be: handle
errors correctly and make sure errors do not result into any sort of resource
leak or sensitive information disclosure.

For example, this code was from a guy in Stack Overflow:

    
    
        ... function (req, res, next) {
            if (err) return console.log(err)
    

What will that piece of code do? Leak the request object, the response object,
including the underlying client connection... keep the connection open, leak
memory... and at scale, make your server run out of sockets and memory. Then,
when memory is low, swapping kicks in, overloading your CPU as well. In short,
kills your machine with only a little 1 line of code mistake.

There are less trivial ways of running into the same situation, but the lesson
is that node.js is not a babyproofed technology and needs to be used with
care.

This piece of advice is one of the most important, and the most
overlooked/ignored in the node community.

~~~
slackingoff2017
Well, I've avoided the node hype because of people warning about bad debugging
experience. With that, I'm going to try to avoid touching it ever.

I've used many web stacks over the years and not a single one defaults to
blowing up like that. They all follow proper modularization... The framework
cleans up objects that the framework creates, you deal with yours.

In any other framework forgetting to end the request would result in the
request automatically ending when your code finishes. This includes Vert.x and
Undertow which are just as asynchronous as Node(but also multithreaded).

Also how the hell does that leak memory? Is JS reference counting that bad?
I've done some really stupid things in Java and C# but never leaked memory
enough that it mattered.

~~~
partycoder
It's not a problem with the garbage collector, just how the objects are
referenced. Basically you need to ensure the request reaches a terminal state
where you either close the connection (ServerResponse.end) or send a response
(ServerResponse.send and similar). All the cleanup happens after you do that.

~~~
slackingoff2017
Is there not an OnDispose or some kind of hook to detect when requests can
end? To end a request in every framework I've used you just return from your
code back to the framework. You shouldn't have to worry about a framework
object like request state.

~~~
partycoder
There are ways to detect this, but since express declares itself as an
"minimalistic, non-opinionated framework" it's up to you to do it and do it
correctly, or have correctly implemented logic that does not run into this
issue.

------
vultour
Prepared statements are amazing. Found out about them very soon after I
started programming (incidentally my first language was PHP), and switched to
PDO right away. This was years ago, I don't understand how people are still
using the deprecated and insecure mysql_* functions, you can still find them
all over SO and my university "web" class was teaching them as well...

~~~
plug
You'll be glad to hear that they've finally been removed since PHP 7.0 so
slowly but surely they're being consigned to history.

And there seems to be much better awareness about the perils of mysql_*
functions amongst PHP devs these days.

However, 5.6 is still in security support until 31st December 2018, so all
that bad advice on SO and elsewhere is still relevant and lurking, waiting to
be found by inexperienced devs.

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

~~~
eropple
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.)

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

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

~~~
aeronautic
No argument on that (except the horseshit ;-)

------
jaequery
Not simple by any means, this one is very thorough and one of the better
security checklist I've come across in a while! Sensedeep looks very
intriguing and I often wondered if anyone has created an alternative to Atomic
Secured Linux. Could this be it? Or is it like an ids / ips with a gui?

~~~
aeronautic
We're just in beta. SenseDeep is part host-IDS and part cloud-side. The key is
real-time. We want to detect attacks in real-time on the server or on the
cloud-side. It has a GUI on top to unify and give a cloud complete view. The
focus is DevOps and not companies with a security team. Not sure if this helps
or confuses things.

~~~
jaequery
Does your product help satisfy any areas of the pci compliance?

~~~
aeronautic
I don't want to take the focus off the post and discussion which was about the
web checklist. You could dm me twitter @SenseDeepSec or email mob. But
briefly, we hit some of the PCI compliance objectives but not all. We expect
to cover more ground in this regard quickly.

------
iovrthoughtthis
Implementation discussions for each of the checks would be handy for those of
us not familiar with all of these practices.

Also those most likely to need such a list.

~~~
aeronautic
Great idea for a follow on post. I'll do that.

------
ryandrake
> 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
app need to authenticate with that service with... a hardcoded secret?

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

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

------
dbg31415
This is great!

Unfortunately this old list hasn't been updated in forever:

* Web Developer Checklist || [http://webdevchecklist.com/](http://webdevchecklist.com/)

------
slackingoff2017
Besides the bad SQL tips most of it is okay. Sounds like the author has little
experience with ORM's or SQL abstraction layers with parameterization like
ADO.NET, SQLAlchemy, or JDBC.

Besides the SQL stuff mentioned elsewhere, Regex is rarely a safe whitelist.
It's better to use specific escapes for HTML or URI or whatever. Most of XSS
is finding bad input that isn't filtered. Hardly anyone is stupid enough to
not filter input at all, but few filter it enough to prevent all XSS.

Also keeping port 22 closed is just silly. If you have secure credentials no
amount of portscanning will hurt you. If you get tired of the logs just move
the port and setup fail2ban. This point is controversial so whatever I guess.

~~~
aeronautic
Thanks for the tips. Can you say which SQL tip is bad, someone has already
picked up the Stored procedure comment -- really meant prepared statements.

Regarding regexp. You can do very precise regexp for many patterns. I agree
some are harder, but I wouldn't say "rarely" in our experience.

The point about port 22 is that if you have it open, many people tend to use
it more than they should. Effective automation should eliminate / greatly
reduce the need for it.

If using AWS/cloud, then you can apply a security group to open when you need,
but otherwise keep it closed at the network level at least. I agree it does
seem to get people all hot an bothered.

~~~
slackingoff2017
A lot of Regex is a hint that you shouldn't be using regex. Regex is a bad
parser and poor sanitizer.

I would wager that more than 50% of XSS vulnerabilities are due to bad regex
when you should be using HTML or URI escape

------
appcraf8
How about extending the same with examples for popular web frameworks like
django RoR?

~~~
aeronautic
I know node better and would be a bit light on other frameworks. Do you have
suggestions?

~~~
appcraf8
Throw across your node work. I will try to replicate the same for RoR. :-)

~~~
aeronautic
When I post the implementation notes for Node, feel free to speak up with the
RoR speak for that item and I'll add it in.

Thank you.

~~~
ianamartin
I'd be happy to try and do a Python version of this. I'm most familiar with
Pyramid, but Flask and Django would be a learning opportunity for me. Much of
this advice I've already implemented in Pyramid.

------
xupybd
> Create immutable hosts instead of long-lived servers that you patch and
> upgrade. (See Immutable Infrastructure Can Be More Secure).

An interesting idea, I've not come across before. Anyone know where I can find
some case studies on this?

~~~
aeronautic
I did a post on that here:

[https://simplesecurity.sensedeep.com/immutable-
infrastructur...](https://simplesecurity.sensedeep.com/immutable-
infrastructure-can-be-dramatically-more-secure-238f297eca49)

but the originator was: Chad Fowler

[http://chadfowler.com/2013/06/23/immutable-
deployments.html](http://chadfowler.com/2013/06/23/immutable-deployments.html)

------
nolikeynovotey
There's some good Android & iOS security checklists here -
[https://codifiedsecurity.com/2017/04/24/mobile-app-
security-...](https://codifiedsecurity.com/2017/04/24/mobile-app-security-
testing-checklist-android/) & [https://codifiedsecurity.com/2017/04/19/mobile-
app-security-...](https://codifiedsecurity.com/2017/04/19/mobile-app-security-
testing-checklist-ios/)

------
pjmorris
"Finally, have a plan"

I'd argue that you're more secure and your life is easier if the plan (threat
model), or at least the planning, come first. The greater your understanding
of your data, users, platform, and attackers, the more likely you are to make
good (e.g. secure, economical) choices about infrastructure, design,
implementation, testing, incident response, etc.

"Plans are nothing; planning is everything." \- Dwight D. Eisenhower

------
adakbar
Is it good to redirect to https when user hit API with http? I have heard
somewhere doing so is bad

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

~~~
thatwebdude
Is 404 sufficient?

~~~
SadWebDeveloper
Depends on your choice, personally i would choose between 410 or 501 but
whatever you choose, just don't allow an implicit redirect with any of the
301/302 codes.

------
SadWebDeveloper
General guidance mostly, nothing too deep, seems suited for C-level since
there is no discussion on securing the infrastructure (as in hardware, not in
software), deployment and way too heavy on looking at the world "from the
clouds".

------
chvid
Lots of random mostly unnecessary advice that will surely take a simple
project and turn it into a big half-baked unmaintainable mess.

Sorry for the harsh words; but good advice needs to be both practical and
cost-efficient.

~~~
aeronautic
Could you highlight what you think are the important items in a web security
checklist?

------
ams6110
Forgot one:

    
    
       [ ] Don't rely on security-by-checklist.

------
aeronautic
Thanks everyone for some great comments and discussion. Really appreciate your
time and feedback on the article.

I'll fold in the feedback and the ideas and go forward with it.

Thanks all

OP: Michael O'Brien

------
nnaumann
Simple Web Developer Checklist:

#1 make sure the css stylesheets are loading

~~~
slackingoff2017
I like this better

------
EGreg
I would add one more regarding DOS protection:

Sign the session tokens that you issue.

This way you don't need to do any I/O to verify these tokens at the router
level.

~~~
aeronautic
I'm not sure I fully understand what you are saying. Can you elaborate.

~~~
EGreg
I came up with this technique when designing our platform
([https://qbix.com/platform](https://qbix.com/platform)) so I don't know if
it's widely used.

Many apps include session id tokens in requests, to identify the logged-in
user. The session id is usually a bearer token (like in a cookie) which
identifies the session on the server.

To mitigate against DDOS attacks, as you said, all publicly available
resources can be cached on CloudFlare. (Personally I look forward to content-
addressable protocols like IPFS supplanting HTTP.)

However, the non-public resources are usually dynamic and should not be
cached. These resources are typically for users who have logged in, or at
least have a session.

So our design basically encourages this:

1) if you want to serve non cacheable resources, require that the request
included a session id

2) the session id is generated on our server _and signed with an HMAC_ so the
app can verify this signature _without_ doing any I/O.

This is because I/O is expensive and hard to parallelize, whereas statelessly
checking whether a session token has been issued by our app is easy to
implement, even at the external router level. Simply examine the packets
coming in, decrypt, look at the request, and verify the HMAC on the session
id. If it is wrong then the session id is bogus so we don't expend any more
resources within the network on this request.

You can make sessions expensive to start. For example, a user might have to
log in with a valid account to get a session.

The big question is, how can we ensure that users don't get too many accounts?
To prevent sybil attacks. Any ideas?

------
winut23
Isn't best practice when it comes to passwords to actually choose a good one,
use a password safe, and _not_ rotate?

~~~
aeronautic
Both. You want to choose a good password and then not let it get too stale. A
very old password (say 1 year) has a higher chance of being subverted purely
because there is more elapsed time wherein attackers could have gained access.

Choose good passwords, long, special chars, preferably random and generated by
a password generator / manager. And then change periodically. That period
depends on your application.

We change our cloud passwords and keys every 90 days.

~~~
rubidium
"A very old password (say 1 year) has a higher chance of being subverted
purely because there is more elapsed time wherein attackers could have gained
access."

Any actual evidence for this? My counter-hypothesis is if your password lasts
6 months of attempted hacks it'll last >6 years (unless social engineering
attempts succeed).

I ask because rotating goes against the current NIST password guidance. In
fact, for your recommendation "Implement simple but adequate password rules
that encourage users to have long, random passwords", I'd recommend pointing
people in that direction.

~~~
aeronautic
Sorry, I should be clearer (late here).

With time passing, the chance of you or anyone with access to the password
being socially engineered, or some other human error, or a hack on your PC
desktop systems, increases linearly with time. The password may last a decade
of brute force cracking, but we humans .... continue to make mistakes far more
frequently.

So rotating passwords protects against the accumulation of human mistakes and
insider threats.

If you are using proper hashing, then your passwords should be safe even if
the hashes are compromised.

Could you please point to the NIST recommendation you mention. I thought they
said that you should NOT force customers to change passwords. But that is
different to you rotating your own critical passwords at a time of your
choosing and on your policy.

~~~
pgsandstrom
Rotating passwords will only help in a very specific situation: When the
password has been leaked, but you have not yet been hacked.

If someone has already gained access to the system, changing passwords are not
sufficient.

If no one has gained access to the system, rotating passwords does not protect
you against social engineering.

~~~
aeronautic
Nicely said.

The one mod I'd suggest is:

If someone has gained access to the passwords and has not used the password
yet or was not interesting in directly using the password themselves, but
rather, they on sold it. There is a window of opportunity that rotation helps.

For example: you may be on one of the password lists being sold in the dark
web. The owner of the list isn't hacking you, but those purchasing the list
will some time soon.

So more specifically, you could be compromised by malware on a PC holding the
password and that password may be extracted, sold and may not be used against
you for months. Rotation helps in this case which is more common than we care
to admit.

------
horsecaptin
How much of this is built into various frameworks such as Rails, Django,
EmberJS (for frontend) etc?

~~~
aeronautic
No much at all.

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

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

------
Gmo
@aeronautic, there's a typo on your website front page : "acccount" with 3 c.

------
type0
Security is a process and not a product of some checklist.

------
xanderjanz
Apparenlty written by somebody who isn't responsible for the actual web
development themselves, just upfixed web devs work for enterprise pen testing.

~~~
aeronautic
Sorry, not true. Spent many years doing full stack web dev and security.
Please offer some constructive criticism - gladly received.

~~~
softawre
You are the OP HN needs but not the one we deserve...

------
slackingoff2017
Come on man, 4 submissions in 5 days all leading to your startup's website?
And a profile created 5 days ago with zero comments on anything you didn't
post?

You could at least try to make it look like you're doing more than promoting
your startup.

~~~
aeronautic
Been an avid HN reader for ages, but been seriously heads down doing the
startup thing for about a year with zero time for blog or posting. Insane
hours. Started surfacing a month ago so I can do more than just code and
wanted to share a bit.

Not trying to hide the company, in fact pretty proud of it and the new things
we're doing. But we are very early stage and still in beta.

I do want to add value through the posts and discussion like this regardless.

------
jwr
I do not like this list.

> [ ] Use minimal privilege for the database access user account. Don’t use
> the database root account.

This advice seems outdated. In general, every significant security breach will
get the attacker root access. Playing games with database accounts gets you no
security at all, while introducing lots of friction and headache.

~~~
spydum
Sorry, you don't throw away mitigation techniques because they aren't
foolproof. This is still excellent advice. Stop using sa and root accounts for
your apps.

~~~
retro64xyz
I agree with Spydum. The reason I agree is - Layers of security are required.
You should not use a root account for your web application. You should also
use escaping, properly formed queries, and prepared statements. You use best
practices in an orderly manner and you will be much safer than just picking
one "silver bullet". Not every attack provides root access to the database or
server. Why make it easier for folks? Least privilege is a viable tool in your
bag.

