A List of Secure Defaults

I do a lot of work at the intersection of Continuous Application Security a.k.a DevSecOps, and Threat Modeling. I see that companies have started to take both these disciplines very seriously, especially today. This is not surprising. When you have rapid application delivery processes, the need to pre-empt security flaws from ruining the party, suddenly seems to be very important.

One of the ways that organizations achieve durable and lasting Application Security success is by eliminating entire classes of flaws in their population of apps. What does this mean? Let me explain...

Suppose you are dealing with your developers using SHA-1 for password hashes and using 3DES for encrypting sensitive data in ECB mode, a la Adobe (below) then you clearly have an issue that is likely pernicious.

You're now left with some options:

1. Train them, multiple times a year if necessary about cryptographic bad and good practices and hope they follow them
2. Eliminate the entire class of flaws with "Secure Default" Libraries

Option 1 is important. Training and awareness is critical, especially in the long-run.

However, Option 2 sounds pretty awesome. How do you do that? Read on...

Option 2 would essentially look like this:

• Identify/Develop libraries that your developers can use for cryptography, that makes it impossible for them to use insecure cryptographic practices. In this case:
• Library forces them to use key-stretching algos like Argon2 and BCrypt for password storage
• Library forces them to use strong cryptographic algos like AES-GCM 128 at the very least.
• Library handles Key generation, Padding and all other crap that makes developers not understand, and thereby introduce several mistakes.

Option 2 largely ensures that you have long-standing security best practices, by default, when developers use these libraries, thereby increasing the security of your application, without having to resort to the developer's knowledge or discretion in trying to avoid introducing these flaws in your application.

In fact, Option 2 has been the focal point of Clint Gibler's excellent talk at OWASP AppSec California earlier this year. [link]

I have started to collect, test and curate, libraries that I think fall into the category of Security Defaults. These are some of the libraries and their categories (by no means exhaustive). If you can think of others that can be added to this list. Please ping me and Ill add them to this list. The idea here is to serve as a useful list for you and your teams to use:

Cryptography

• LibSodium
• Google's Tink

Client-Side Output Encoding

• DOMPurify
• Bleach

Input Validation

• JSON-Schema (More a framework for input validation secure defaults)
• Express-Validator (More a framework for Input Validation Secure Defaults)
• Validator.js

Database Access (RDBMS)

• An ORM - Please validate that these libraries are not vulnerable to injection themselves

Other Injection

• Mustache - Low-Logic Templating preventing Server-Side Template Injection
• Safe-Regex: Preventing against unsafe regex patterns that trigger ReDOS
• SerialKiller: Look-Ahead Deserialization for Java

HTTP Security Headers

• Helmet - NodeJS