Alignment with OWASP Proactive Controls

I committed PR #374 which adds this sentence. The real work has been many other commits which I have made over the last few days to ensure that the ASVS includes all the points included in the proactive controls list.

The rating point now seems to be irrelevant as the most recent suggestion is that L1 should only be things which are testable via grey-box although I will make a note that at the end someone should verify that all the controls below are L2.

For future reference here is the mapping I came up with:

Edit: Ignore the below, this mapping is too painful to maintain. I added a link to every relevant control in PR #534

IGNORE THE REST OF THIS COMMENT -----------------------------------------------------------------------

C1: Define Security Requirements

#	Description
1.1.5	A high-level architecture for the application and all connected remote services has been defined and security has been addressed in that architecture.
1.1.1	Security is addressed within all parts of the software development lifecycle.

C2: Leverage Security Frameworks and Libraries

#	Description
14.2.4	Verify that third party components come from pre-defined, trusted and continually maintained repositories.
14.2.1	Verify that all components are up to date with proper security configuration(s) and version(s), preferably using a dependency checker during build or compile time.
14.2.5	An inventory catalog is maintained of all third party libraries in use.
14.2.6	Verify that the attack surface is reduced by encapsulating third party libraries to expose only the required behaviour into the application.

C3: Secure Database Access

#	Description
5.2.1	Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks.
5.3.6	Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection.
1.2.2	Verify that communications between application components, including APIs, middleware and data layers, are authenticated with the least necessary privileges.
1.2.1	Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers.
1.9.1	Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.

C4: Encode and Escape Data

#	Description
5.3.1	Verify that output encoding occurs close to or by the interpreter for which it is intended.
5.2.2	Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, URL Parameters, HTTP headers, SMTP, and others as the context requires.
5.2.3	Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled.
5.2.4	Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.
5.2.5	Verify that any user-supplied data included in the browser's DOM or web views protects against JavaScript code execution and XSS attacks.
5.2.6	Verify that where parameterized or safer mechanisms are not present, that context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection.
5.3.3	Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.
5.3.5	Verify that the application protects against XPath injection or XML injection attacks.
5.3.2	Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented.

C5: Validate All Inputs

#	Description
5.1.1	Verify that server-side input validation failures result in request rejection and are logged.
5.1.2	Verify that input validation is enforced on the server-side.
5.1.4	Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature.
5.1.6	Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting).
5.1.7	Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as validating suburbs and zip or postcodes match).
5.3.9	Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar.
5.4.4	Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.
19.1.2	Verify application deployments are adequately sandboxed, containerized and/or isolated at the network level to delay and deter attackers from attacking other applications, especially when they are performing sensitive or dangerous actions such as deserialization.
8.3	Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures.

C6: Implement Digital Identity

#	Description
2.4.1	Verify that passwords are at least 8 characters in length.
2.4.2	Verify that passwords 64 characters or longer are permitted.
2.4.3	Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced.
2.4.6	Verify that new or changed passwords are validated against a list of compromised secrets, and if found to be compromised, the user is prompted to choose another secret.
2.4.8	Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.
2.3.1	Verify that a system generated activation or recovery password is not sent in clear text to the user.
2.3.3	Verify password credential recovery does not reveal the current password in any way.
2.3.4	Verify forgotten password, and other recovery paths use a TOTP or other soft token, mobile push, or another offline recovery mechanism.
2.5.1	Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, and a cost factor as inputs then generate a password hash.
2.5.2	Verify that the salt is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each credential, a unique salt value and the resulting hash SHALL be stored.
2.5.3	Verify that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,000 iterations.
2.5.4	Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, typically at least 13.
3.2.1	Verify that session tokens are created or generated after authentication, not before.
3.2.2	Verify that session tokens are created using approved cryptographic algorithms with at least 64 bits of entropy.
3.3.2	Verify that absolute or idle timeouts invalidates or erases any client- or server-side session storage.
3.3.3	Verify if authenticators permit users to remain logged in, that re-authentication occurs periodically both when actively used or after an idle period.	30 days	12 hours or 30 minutes of inactivity, 2FA optional	12 hours or 15 minutes of inactivity, with 2FA
3.4.1	Verify that cookie-based session IDs have the 'Secure' attribute.
3.4.2	Verify that cookie-based session IDs have the 'HttpOnly' attributes.
3.4.3	Verify that cookie-based session IDs have minimum practical hostnames, domain and path attributes, along with the 'SameSite' attribute.
3.4.4	Verify that cookie-based session IDs are set to expire soon after the default session timeout period.

C7: Enforce Access Controls

#	Description
4.1.1	Verify that the chosen access control solution is flexible enough to meet the application's needs.
4.1.5	Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
4.1.6	Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until this is explicitly assigned.
4.2.1	Verify that there is only one vetted access control mechanism for protecting access to protected data and resources which all requests must go through. This should mean that hard coded access control checks are not required throughout the application.
4.2.2	Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles.
4.1.8	Verify that all access control decisions can be logged and all failed decisions are logged.

C8: Protect Data Everywhere

#	Description
9.2	Identify all sensitive data created and processed by the application and ensure that a policy is in place on how to deal with sensitive data.
10.2	Verify that TLS is used for all connections (including for authentication, API or web service calls, backend, external, and partner connections), and does not fall back to insecure or unencrypted protocols.
9.13	Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity.
7.3.1	Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.
7.5.1	Verify that a secrets management solution such as a key vault is used to main secrests rather than code, config files or environment variables.
7.3.4	Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks.
7.2.1	Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.
7.2.2	Verify that all keys and passwords are replaceable and are part of a well defined process to re-encrypt sensitive data.

C9: Implement Security Logging and Monitoring

#	Description
8.11	Verify that a common logging format and approach is used across the system.
8.4	Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens.
8.1	Verify that the application does not log credentials, session tokens or payment details.
8.2	Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy.
8.9	Verify that time sources are synchronized to the correct time and time zone.
15.4	Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt.
8.5	Verify that all events are protected from injection when viewed in log viewing software.
8.6	Verify that security logs are protected from unauthorized access and modification.
8.7	Verify that the application appropriately encodes user-supplied data to prevent log injection.
8.8	Verify that logs are transmitted to a remote system for analysis, detection, alerting, and escalation.

C10: Handle all Errors and Exceptions

#	Description
1.8	All security controls have a centralized implementation as to avoid duplication of critical code.
4.1.7	Verify that access controls fail securely including when an exception occurs.
3.1.1	Verify that the session token is never disclosed in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.
8.2.1	Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate.
8.3.2	Verify that exception handling is used across the codebase to account for expected and unexpected error conditions.
8.3.3	Verify that a "last resort" error handler is defined which will catch all unhandled exceptions.

OWASP / ASVS

Alignment with OWASP Proactive Controls #322