11–20 of 71 posts
Where is the actual guide? Is this the TOC for a book? It looks good but I don't see the actual content, just a check list and a table of contents.
Exactly! Where are the doc to all the sections? This seems terribly important stuff, but it looks like a 'teaser' to a book? If not where do we get the information for each section?
My reason for this belief is that, in my experience, it engenders tunnel vision and what I appropriately refer to as a "checklist mentality". There are developers who believe, "We're immune to the items on the OWASP Top 10, so we're secure," when there are entire classes of vulnerabilities that applications can be vulnerable to (say: using a weak and predictable PRNG for their password reset tokens) that isn't adequately described by the OWASP Top 10.
An alternative approach that I feel is more helpful is to organize insecurity into a taxonomy.
* Code/data confusion
* SQL Injection
* Local/Remote File Inclusion
* Cross-Site Scripting (XSS)
* LDAP Injection
* XPath Injection
* Several memory corruption vulnerabilities
* Logic Errors
* Confused deputies
* CSRF
* Failure to enforce access controls
* Operating Environment
* Using software with known vulnerabilities
* Using HTTP instead of HTTPS
* Cryptography flaws
* Yes, this deserves a category of its own
* Chosen-plaintext attacks
* Chosen-ciphertext attacks
* Side-channel cryptanalysis
* Hash collision vulnerabilities (e.g. length-extension)
* Weak/predictable random values
There are three types of XSS (stored, reflective, DOM-based). There are blind SQL injection techniques worth studying too. But the underlying problem that makes these vulnerabilities possible is simple: User-provided data is being treated as code. Any technology that prevents this confusion will greatly improve security.
For example: SQL injection is neutered by using prepared statements. You might one day forget to manually escape a single input (and it only takes one to be game over), but if user data is always passed separately from the query string (i.e. you never concatenate), there's no opportunity to make this mistake. There were also corner-case escaping bypass attacks (usually involving Unicode) that you might not be vulnerable to. With prepared statements, these clever multibyte character tricks accomplish nothing. The query string is already in the database server before your user's parameters are sent.
I believe teaching developers to think in terms of taxonomy (very general to very specific) will result in a greater understanding of software security and reduce the incidence of vulnerable code.
I've written about this before, in case anyone wants to link to something besides an HN comment: https://paragonie.com/blog/2015/08/gentle-introduction-appli...
---
EDIT: Opened an issue: https://github.com/FallibleInc/security-guide-for-developers...
The first thing jumped out is: Store password hashes using Bcrypt (no salt necessary - Bcrypt does it for you) A better approach would be recommending storing password with password-based key derivation functions (recommendation: scrypt or bcrypt). I don't want to start the whole debate of scrypt vs bcrypt, GPU vs FPGA here (not qualified and we keep repeating the conversation every time the vs is on the table). - Wh…
> Check for no/default passwords for databases especially MongoDB & Redis. BTW MongoDB sucks, avoid it.
But one of the most serious problems with web development is how few frameworks ship with most of these sane answers out-of-the-box (edit: or don't ship concepts at the right level of abstraction)
When we all need to copy-paste some best-practice way of how to Argon2 a password and how to constant-time equality check a hash, we've already lost, in that we're reimplemeting these sane answers every time from the weeds.
I want to see more things like Django's automatic password hash upgrading [1].
Specifically, checklists like this effort's should be for people who develop frameworks, and not people who develop custom apps with them. With some things like CSRF protection, we're already there, but with so many other things, we're not.
[1] https://docs.djangoproject.com/en/1.9/topics/auth/passwords/...
Had this SO link saved since probably soon after it was asked 7 years ago. Still relevant and still being updated. http://stackoverflow.com/questions/549/the-definitive-guide-... Includes: - How to log in - How to remain logged in - Managing cookies (including recommended settings) - SSL/HTTPS encryption - How to store passwords - Using secret questions - Forgotten username/password functionality - Use of nonces to p…
Please excuse me if this comes across as anything other than constructive criticism, but I don't believe checklists should be used to guide web developers to build secure software. My reason for this belief is that, in my experience, it engenders tunnel vision and what I appropriately refer to as a "checklist mentality". There are developers who believe, "We're immune to the items on the OWASP Top 10, so we're secure…
The categories in your list are important, but I suggest adding what I consider the most important idea in security: stop designing features in a way that requires an enumeration of badness[1], aka default permit is always a bad idea. Checking for known problems inherently skips anything new.
Instead, anything that arrives over the net or other hostile input needs to be validated with a formal recognizer. For a good explanation of this approach, see Meredith and Sergey's 28c3 talk, "The Science of Insecurity"[2].
[1] http://www.ranum.com/security/computer_security/editorials/d...
[2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
[0] Security for building modern web apps https://dadario.com.br/security-for-building-modern-web-apps... [1] https://www.owasp.org
Had this SO link saved since probably soon after it was asked 7 years ago. Still relevant and still being updated. http://stackoverflow.com/questions/549/the-definitive-guide-... Includes: - How to log in - How to remain logged in - Managing cookies (including recommended settings) - SSL/HTTPS encryption - How to store passwords - Using secret questions - Forgotten username/password functionality - Use of nonces to p…