How much of this is built into various frameworks such as Rails, Django, EmberJS (for frontend) etc?
No much at all.
Web Developer Security Checklist
21–30 of 249 posts
Re: Web Developer Security Checklist
#22"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.
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
Actually yes, this. Good call out.
Re: Web Developer Security Checklist
#23> 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?
Netflix is notable for doing this with all their infrastructure. You could probably find some presentations by them about it. Martin Fowler wrote about it, so that would be a good place to start.
Re: Web Developer Security Checklist
#24While 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…
I take your point that this could be explained a lot better. In the next revision when I fold in the feedback, I'll make this clearer. One suggestion, that I'll do is pair each checklist item with an implementation note that explains it better. Thanks for pointing out the flaws.
Re: Web Developer Security Checklist
#25While 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…
The cost of full encryption is minimal on platforms like AWS Aurora. If the platform supports it - this is a good way to go. The incremental cost of encryption with Aurora is very low ( The 2nd layer is if the server-app is compromised. In this case, the data has already been decrypted by AWS. The 2nd layer means that credentials, emails etc are safe in the server-app tier. You can lookup tokens by decrypting first.…
> At rest, means that the data on disk is encrypted if the DB itself is compromised
Right, so basically block-level encryption of the actual DB data file. While this would be much easier than encrypting the record data at the row level, it only protects against literal copying of the data file, which in my experience is not a common threat vector.
You're right though, it is simple enough to do this with something like aurora - although outside of AWS it may be very troublesome, with possible performance ramifications.
I guess my point is that this article is presented as a basic checklist for all web apps, with insufficient consideration of the ROI for implementing these solutions.
> You can lookup tokens by decrypting first
A user attempts to access your API, presenting an access token. How do you query your DB for that access token if all your tokens are encrypted at the row level? You could encrypt it at the app level and search for the cyphertext, sure, but now your server needs to have the secret, and it needs to be global, seemingly removing the point. Every other aspect of your application (notifications engine, admin portal, anything else that needs the DB) must re-implement this scheme.
Again, it might be useful, but the ROI is questionable, IMO.
> Regarding prepared statements
I misspoke here really - my reaction was against the stored procedures, not prepared statements, which are great and should be used whereever possible.
My main point is that security, and all development really, is about trade-offs. The options here are presented without due consideration of the benefits and costs of the tradeoffs they represent - and they article doesn't ask you to just "think" about them, it's a checklist. If you are a bank with 500 developers and unlimited time, sure, do all of these. If you're a startup - questionable at best.
Re: Web Developer Security Checklist
#26While 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…
I take your point that this could be explained a lot better. In the next revision when I fold in the feedback, I'll make this clearer. One suggestion, that I'll do is pair each checklist item with an implementation note that explains it better. Thanks for pointing out the flaws.
Ah, I didn't realise you were the author!
Sorry for coming on a little strong. I should wait a few minutes before tearing into things...
The article is a great beginning, and as we have seen, definitely a conversation-starter! So thanks for creating it.
What I'm scared of, though, is non-technical people finding articles like this and, without a thorough understanding of the tradeoffs involved, presenting it as a list of requirements for their team. That's probably not what you intended - but I've seen this kind of thing happen again and again.
Re: Web Developer Security Checklist
#27Earlier quoted context omitted.
The cost of full encryption is minimal on platforms like AWS Aurora. If the platform supports it - this is a good way to go. The incremental cost of encryption with Aurora is very low ( The 2nd layer is if the server-app is compromised. In this case, the data has already been decrypted by AWS. The 2nd layer means that credentials, emails etc are safe in the server-app tier. You can lookup tokens by decrypting first.…
> At rest, means that the data on disk is encrypted if the DB itself is compromised Right, so basically block-level encryption of the actual DB data file. While this would be much easier than encrypting the record data at the row level, it only protects against literal copying of the data file, which in my experience is not a common threat vector. You're right though, it is simple enough to do this with something lik…
Good point. I did say:
"This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application."
But I'll try to make that clearer. I'm limited by space and peoples attention span. Having links to implementation notes will address your concern I think.
Re: Web Developer Security Checklist
#28Earlier quoted context omitted.
I take your point that this could be explained a lot better. In the next revision when I fold in the feedback, I'll make this clearer. One suggestion, that I'll do is pair each checklist item with an implementation note that explains it better. Thanks for pointing out the flaws.
Ah, I didn't realise you were the author! Sorry for coming on a little strong. I should wait a few minutes before tearing into things... The article is a great beginning, and as we have seen, definitely a conversation-starter! So thanks for creating it. What I'm scared of, though, is non-technical people finding articles like this and, without a thorough understanding of the tradeoffs involved, presenting it as a lis…
No problem, all feedback is good.
Lucky I've got my asbestos pants on ;-)
Re: Web Developer Security Checklist
#29Earlier quoted context omitted.
I know node better and would be a bit light on other frameworks. Do you have suggestions?
Throw across your node work. I will try to replicate the same for RoR. :-)
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.
Re: Web Developer Security Checklist
#30Simple Web Developer Checklist:
#1 make sure the css stylesheets are loading