Secure Coding

Alicia Sykes

The defender must be right every time.
The attacker only needs to be right once.

Source: cybermap.kaspersky.com

Threat Modelling

Common Attacks

Injection


							String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

thing

Insecure Design

Scenario #1: A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are prohibited. Such code should be removed and replaced with a more secure design. Scenario #2: A cinema chain allows group booking discounts and has a maximum of fifteen attendees before requiring a deposit. Attackers could threat model this flow and test if they could book six hundred seats and all cinemas at once in a few requests, causing a massive loss of income. Scenario #3: A retail chain’s e-commerce website does not have protection against bots run by scalpers buying high-end video cards to resell auction websites. This creates terrible publicity for the video card makers and retail chain owners and enduring bad blood with enthusiasts who cannot obtain these cards at any price. Careful anti-bot design and domain logic rules, such as purchases made within a few seconds of availability, might identify inauthentic purchases and rejected such transactions.

Broken Access Control

CORS

(I'm sorry)

So how does CORS help us secure our site?

Access Control Design Principles

Design Access Control Thoroughly Up Front
Force All Requests to Go Through Access Control Checks
Deny by Default
Principle of Least Privilege
Don't Hardcode Roles
Log All Access Control Events

Cryptographic Failures

Failure to handle data properly and securely leads to sensitive data being exposed. The selling of this data has grown to a multi-billion dollar industry, with the effects of the breached companies and their clients being very significant.

As developers, we need to take a step back, and think about what data we're storing, how it's stored, accessed, transmitted and updated.

Don't store sensitive data that isn't 100% necessary
Encrypt all sensitive data both at rest, and in transit
Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management
Apply the correct access controls, as per the datas clasification
Disable caching for response that contain sensitive data
Always use authenticated encryption instead of just encryption.

Security Misconfiguration

Vulnerable and Outdated Components

Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g., coding error) or intentional (e.g., a backdoor in a component).

NPM Security Best Practices