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.
this.
Web Developer Security Checklist
131–140 of 249 posts
Re: Web Developer Security Checklist
#132@aeronautic, there's a typo on your website front page : "acccount" with 3 c.
Re: Web Developer Security Checklist
#133While 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…
>> 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?
Re: Web Developer Security Checklist
#134Hope 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.
Agreed. The original title of "Web Developer Security Checklist" is much better.
Re: Web Developer Security Checklist
#135"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. 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.
Re: Web Developer Security Checklist
#136How much of this is built into various frameworks such as Rails, Django, EmberJS (for frontend) etc?
EmberJS handles all the aspects that purely browser-based application code can - protecting from XSS attacks, setting up your Content Security Policy, and client side input validation.
Re: Web Developer Security Checklist
#137While 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?
This is actually possible, it's just very easy to make over-complicated: https://paragonie.com/white-paper/2015-secure-php-data-encry...
I wouldn't recommend encrypting all data. I also wouldn't recommend using unauthenticated encryption, which the article doesn't address.
Re: Web Developer Security Checklist
#138> 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?
Re: Web Developer Security Checklist
#139Forgot one:
[ ] Don't rely on security-by-checklist.Re: Web Developer Security Checklist
#140Earlier quoted context omitted.
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?
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.
I see. Makes sense. Thanks for sharing this approach.