Security Unit Tests

One of the reasons why security creates a challenge in software companies, is that, as a security engineer, we fail to meet the developers where they live.

Security tools and processes (pentests) typically result in a human report , or even a particular standardized file format (SARIF, etc).

During technical security reviews, teams often file bugs and do a manual re-check.  They explain what the issue is, rate its risk, give perhaps a detailed remediation plan (rather than a vague “check for malicious user input”), and may retest it when the developer team claims to have fixed the bug.  

A better way to tackle this is to prepare security unit tests.  These are essentially unit tests that check for a security control.  For example, classes such as:

• Client certification validation
• OAuth2 Token validation
• File upload validation
• WebRequest validation

Testing these could be more automated, and done in a more continuous way.  If one has a Web endpoint that allows client cert authentication, which is signed by our intermediate CA, and have a whitelisted SNI.  For that, we run the following list of tests:

• Authenticate with the correct certificate (should succeed)
• Cert with valid SNI, signed by a malicious CA (should fail)
• Certificate with the wrong SNI, but the correct CA (should fail)
• Expired certificate, yet the correct SNI and CA (should fail)
• Revoked cert (SNI, not expired, CA) (should fail)

Some libraries that perform certificate validation, may not perform all checks (CRL check).  For debugging purposes, a developer may include a “fail open” fallback, and that code may be checked in and be deployed to production.

Some more examples:

• File uploads: check for zip bombs, embedded ZIP’s, malware, malformed formats, XXE, Deserialization, etc. 
• JWT token validation: look at unsigned tokens, expired tokens, tokens that are generated – and signed- by the wrong issuer, tokens for the wrong audience, wrong signing algorithms (HS* compared to RS*), etc.
• …

So, to summarize, instead of just human output, security tools and processes should still think about creating unit tests.