diff --git a/4.0/en/0x10-V1-Architecture.md b/4.0/en/0x10-V1-Architecture.md index 371e965bf4..dc6fcbad67 100644 --- a/4.0/en/0x10-V1-Architecture.md +++ b/4.0/en/0x10-V1-Architecture.md @@ -1,4 +1,4 @@ -# V1: Architecture, Design and Threat Modeling Requirements +# V1 Architecture, Design and Threat Modeling ## Control Objective @@ -10,7 +10,7 @@ If developers had invested in a single, secure identity provider model, such as In this chapter, the ASVS covers off the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. Each of these security principles must be built in and be innate to all applications. It is critical to "shift left", starting with developer enablement with secure coding checklists, mentoring and training, coding and testing, building, deployment, configuration, and operations, and finishing with follow up independent testing to assure that all of the security controls are present and functional. The last step used to be everything we did as an industry, but that is no longer sufficient when developers push code into production tens or hundreds of times a day. Application security professionals must keep up with agile techniques, which means adopting developer tools, learning to code, and working with developers rather than criticizing the project months after everyone else has moved on. -## V1.1 Secure Software Development Lifecycle Requirements +## V1.1 Secure Software Development Lifecycle | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | @@ -22,7 +22,7 @@ In this chapter, the ASVS covers off the primary aspects of any sound security a | **1.1.6** | Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 637 | | **1.1.7** | Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers. | | ✓ | ✓ | 637 | -## V1.2 Authentication Architectural Requirements +## V1.2 Authentication Architecture When designing authentication, it doesn't matter if you have strong hardware enabled multi-factor authentication if an attacker can reset an account by calling a call center and answering commonly known questions. When proving identity, all authentication pathways must have the same strength. @@ -33,11 +33,11 @@ When designing authentication, it doesn't matter if you have strong hardware ena | **1.2.3** | Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches. | | ✓ | ✓ | 306 | | **1.2.4** | Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application. | | ✓ | ✓ | 306 | -## V1.3 Session Management Architectural Requirements +## V1.3 Session Management Architecture This is a placeholder for future architectural requirements. -## V1.4 Access Control Architectural Requirements +## V1.4 Access Control Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | @@ -47,7 +47,7 @@ This is a placeholder for future architectural requirements. | **1.4.4** | Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 284 | | **1.4.5** | 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. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 275 | -## V1.5 Input and Output Architectural Requirements +## V1.5 Input and Output Architecture In 4.0, we have moved away from the term "server-side" as a loaded trust boundary term. The trust boundary is still concerning - making decisions on untrusted browsers or client devices is bypassable. However, in mainstream architectural deployments today, the trust enforcement point has dramatically changed. Therefore, where the term "trusted service layer" is used in the ASVS, we mean any trusted enforcement point, regardless of location, such as a microservice, serverless API, server-side, a trusted API on a client device that has secure boot, partner or external APIs, and so on. @@ -60,7 +60,7 @@ The "untrusted client" term here refers to client-side technologies that render | **1.5.3** | Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 602 | | **1.5.4** | Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 116 | -## V1.6 Cryptographic Architectural Requirements +## V1.6 Cryptographic Architecture Applications need to be designed with strong cryptographic architecture to protect data assets as per their classification. Encrypting everything is wasteful, not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high level design, design sprints or architectural spikes. Designing cryptography as you go or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start. @@ -73,34 +73,34 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi | **1.6.3** | Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data. | | ✓ | ✓ | 320 | | **1.6.4** | Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data. | | ✓ | ✓ | 320 | -## V1.7 Errors, Logging and Auditing Architectural Requirements +## V1.7 Errors, Logging and Auditing Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **1.7.1** | Verify that a common logging format and approach is used across the system. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 1009 | | **1.7.2** | Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | | -## V1.8 Data Protection and Privacy Architectural Requirements +## V1.8 Data Protection and Privacy Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **1.8.1** | Verify that all sensitive data is identified and classified into protection levels. | | ✓ | ✓ | | | **1.8.2** | Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture. | | ✓ | ✓ | | -## V1.9 Communications Architectural Requirements +## V1.9 Communications Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **1.9.1** | Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 319 | | **1.9.2** | Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains. | | ✓ | ✓ | 295 | -## V1.10 Malicious Software Architectural Requirements +## V1.10 Malicious Software Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **1.10.1** | Verify that a source code control system is in use, with procedures to ensure that check-ins are accompanied by issues or change tickets. The source code control system should have access control and identifiable users to allow traceability of any changes. | | ✓ | ✓ | 284 | -## V1.11 Business Logic Architectural Requirements +## V1.11 Business Logic Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | @@ -108,18 +108,18 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi | **1.11.2** | Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state. | | ✓ | ✓ | 362 | | **1.11.3** | Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions. | | | ✓ | 367 | -## V1.12 Secure File Upload Architectural Requirements +## V1.12 Secure File Upload Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **1.12.1** | Verify that user-uploaded files are stored outside of the web root. | | ✓ | ✓ | 552 | | **1.12.2** | Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file. | | ✓ | ✓ | 646 | -## V1.13 API Architectural Requirements +## V1.13 API Architecture This is a placeholder for future architectural requirements. -## V1.14 Configuration Architectural Requirements +## V1.14 Configuration Architecture | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | diff --git a/4.0/en/0x11-V2-Authentication.md b/4.0/en/0x11-V2-Authentication.md index 6b1f60de40..8d725b64f5 100644 --- a/4.0/en/0x11-V2-Authentication.md +++ b/4.0/en/0x11-V2-Authentication.md @@ -1,4 +1,4 @@ -# V2: Authentication Verification Requirements +# V2 Authentication ## Control Objective @@ -30,7 +30,7 @@ Applications can always exceed the current level's requirements, especially if m | o | Recommended, but not required | | ✓ | Required | -## V2.1 Password Security Requirements +## V2.1 Password Security Passwords, called "Memorized Secrets" by NIST 800-63, include passwords, PINs, unlock patterns, pick the correct kitten or another image element, and passphrases. They are generally considered "something you know", and often used as single-factor authenticators. There are significant challenges to the continued use of single-factor authentication, including billions of valid usernames and passwords disclosed on the Internet, default or weak passwords, rainbow tables and ordered dictionaries of the most common passwords. @@ -55,7 +55,7 @@ Credential Service Providers (CSPs) provide federated identity for users. Users Note: The goal of allowing the user to view their password or see the last character temporarily is to improve the usability of credential entry, particularly around the use of longer passwords, passphrases, and password managers. Another reason for including the requirement is to deter or prevent test reports unnecessarily requiring organizations to override built-in platform password field behavior to remove this modern user-friendly security experience. -## V2.2 General Authenticator Requirements +## V2.2 General Authenticator Security Authenticator agility is essential to future-proof applications. Refactor application verifiers to allow additional authenticators as per user preferences, as well as allowing retiring deprecated or unsafe authenticators in an orderly fashion. @@ -71,7 +71,7 @@ NIST considers email and SMS as ["restricted" authenticator types](https://pages | **2.2.6** | Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes. | | | ✓ | 308 | 5.2.8 | | **2.2.7** | Verify intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key. | | | ✓ | 308 | 5.2.9 | -## V2.3 Authenticator Lifecycle Requirements +## V2.3 Authenticator Lifecycle Authenticators are passwords, soft tokens, hardware tokens, and biometric devices. The lifecycle of authenticators is critical to the security of an application - if anyone can self-register an account with no evidence of identity, there can be little trust in the identity assertion. For social media sites like Reddit, that's perfectly okay. For banking systems, a greater focus on the registration and issuance of credentials and devices is critical to the security of the application. @@ -83,7 +83,7 @@ Note: Passwords are not to have a maximum lifetime or be subject to password rot | **2.3.2** | Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens. | | ✓ | ✓ | 308 | 6.1.3 | | **2.3.3** | Verify that renewal instructions are sent with sufficient time to renew time bound authenticators. | | ✓ | ✓ | 287 | 6.1.4 | -## V2.4 Credential Storage Requirements +## V2.4 Credential Storage Architects and developers should adhere to this section when building or refactoring code. This section can only be fully verified using source code review or through secure unit or integration tests. Penetration testing cannot identify any of these issues. @@ -101,7 +101,7 @@ This section cannot be penetration tested, so controls are not marked as L1. How Where US standards are mentioned, a regional or local standard can be used in place of or in addition to the US standard as required. -## V2.5 Credential Recovery Requirements +## V2.5 Credential Recovery | # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | @@ -113,7 +113,7 @@ Where US standards are mentioned, a regional or local standard can be used in pl | **2.5.6** | Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 640 | 5.1.1.2 | | **2.5.7** | Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment. | | ✓ | ✓ | 308 | 6.1.2.3 | -## V2.6 Look-up Secret Verifier Requirements +## V2.6 Look-up Secret Verifier Look up secrets are pre-generated lists of secret codes, similar to Transaction Authorization Numbers (TAN), social media recovery codes, or a grid containing a set of random values. These are distributed securely to users. These lookup codes are used once, and once all used, the lookup secret list is discarded. This type of authenticator is considered "something you have". @@ -123,7 +123,7 @@ Look up secrets are pre-generated lists of secret codes, similar to Transaction | **2.6.2** | Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, salted with a unique and random 32-bit salt and hashed with an approved one-way hash. | | ✓ | ✓ | 330 | 5.1.2.2 | | **2.6.3** | Verify that lookup secrets are resistant to offline attacks, such as predictable values. | | ✓ | ✓ | 310 | 5.1.2.2 | -## V2.7 Out of Band Verifier Requirements +## V2.7 Out of Band Verifier In the past, a common out of band verifier would have been an email or SMS containing a password reset link. Attackers use this weak mechanism to reset accounts they don't yet control, such as taking over a person's email account and re-using any discovered reset links. There are better ways to handle out of band verification. @@ -142,7 +142,7 @@ Unsafe out of band authenticators such as e-mail and VOIP are not permitted. PST | **2.7.5** | Verify that the out of band verifier retains only a hashed version of the authentication code. | | ✓ | ✓ | 256 | 5.1.3.2 | | **2.7.6** | Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient). | | ✓ | ✓ | 310 | 5.1.3.2 | -## V2.8 Single or Multi-factor One Time Verifier Requirements +## V2.8 One Time Verifier Single-factor One-time Passwords (OTPs) are physical or soft tokens that display a continually changing pseudo-random one-time challenge. These devices make phishing (impersonation) difficult, but not impossible. This type of authenticator is considered "something you have". Multi-factor tokens are similar to single-factor OTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing or some additional value (such as transaction signing calculators) to be entered to create the final OTP. @@ -156,7 +156,7 @@ Single-factor One-time Passwords (OTPs) are physical or soft tokens that display | **2.8.6** | Verify physical single-factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location. | | ✓ | ✓ | 613 | 5.2.1 | | **2.8.7** | Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know. | | o | ✓ | 308 | 5.2.3 | -## V2.9 Cryptographic Software and Devices Verifier Requirements +## V2.9 Cryptographic Verifier Cryptographic security keys are smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. Verifiers send a challenge nonce to the cryptographic devices or software, and the device or software calculates a response based upon a securely stored cryptographic key. @@ -168,7 +168,7 @@ The requirements for single-factor cryptographic devices and software, and multi | **2.9.2** | Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. | | ✓ | ✓ | 330 | 5.1.7.2 | | **2.9.3** | Verify that approved cryptographic algorithms are used in the generation, seeding, and verification. | | ✓ | ✓ | 327 | 5.1.7.2 | -## V2.10 Service Authentication Requirements +## V2.10 Service Authentication This section is not penetration testable, so does not have any L1 requirements. However, if used in an architecture, coding or secure code review, please assume that software (just as Java Key Store) is the minimum requirement at L1. Clear text storage of secrets is not acceptable under any circumstances. diff --git a/4.0/en/0x12-V3-Session-management.md b/4.0/en/0x12-V3-Session-management.md index 7ae4ac3568..4be6ce2944 100644 --- a/4.0/en/0x12-V3-Session-management.md +++ b/4.0/en/0x12-V3-Session-management.md @@ -1,4 +1,4 @@ -# V3: Session Management Verification Requirements +# V3 Session Management ## Control Objective @@ -13,13 +13,13 @@ As previously noted, these requirements have been adapted to be a compliant subs ## Security Verification Requirements -## V3.1 Fundamental Session Management Requirements +## V3.1 Fundamental Session Management Security | # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | | **3.1.1** | Verify the application never reveals session tokens in URL parameters. | ✓ | ✓ | ✓ | 598 | | -## V3.2 Session Binding Requirements +## V3.2 Session Binding | # | Description | L1 | L2 | L3 | CWE | [NIST §](https://pages.nist.gov/800-63-3/sp800-63b.html) | | :---: | :--- | :---: | :---:| :---: | :---: | :---: | @@ -30,7 +30,7 @@ As previously noted, these requirements have been adapted to be a compliant subs TLS or another secure transport channel is mandatory for session management. This is covered off in the Communications Security chapter. -## V3.3 Session Logout and Timeout Requirements +## V3.3 Session Termination Session timeouts have been aligned with NIST 800-63, which permits much longer session timeouts than traditionally permitted by security standards. Organizations should review the table below, and if a longer time out is desirable based around the application's risk, the NIST value should be the upper bounds of session idle timeouts. @@ -63,7 +63,7 @@ Token-based session management includes JWT, OAuth, SAML, and API keys. Of these | **3.5.2** | Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations. | | ✓ | ✓ | 798 | | | **3.5.3** | Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks. | | ✓ | ✓ | 345 | | -## V3.6 Re-authentication from a Federation or Assertion +## V3.6 Federated Re-authentication This section relates to those writing Relying Party (RP) or Credential Service Provider (CSP) code. If relying on code implementing these features, ensure that these issues are handled correctly. diff --git a/4.0/en/0x12-V4-Access-Control.md b/4.0/en/0x12-V4-Access-Control.md index 5d9e39f641..1f5e5d8f99 100644 --- a/4.0/en/0x12-V4-Access-Control.md +++ b/4.0/en/0x12-V4-Access-Control.md @@ -1,4 +1,4 @@ -# V4: Access Control Verification Requirements +# V4 Access Control ## Control Objective diff --git a/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md index 2d20e38acf..287a472efb 100644 --- a/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -1,4 +1,4 @@ -# V5: Validation, Sanitization and Encoding Verification Requirements +# V5 Validation, Sanitization and Encoding ## Control Objective @@ -12,7 +12,7 @@ Ensure that a verified application satisfies the following high-level requiremen With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application. -## V5.1 Input Validation Requirements +## V5.1 Input Validation Properly implemented input validation controls, using positive allow lists and strong data typing, can eliminate more than 90% of all injection attacks. Length and range checks can reduce this further. Building in secure input validation is required during application architecture, design sprints, coding, and unit and integration testing. Although many of these items cannot be found in penetration tests, the results of not implementing them are usually found in V5.3 - Output encoding and Injection Prevention Requirements. Developers and secure code reviewers are recommended to treat this section as if L1 is required for all items to prevent injections. @@ -24,7 +24,7 @@ Properly implemented input validation controls, using positive allow lists and s | **5.1.4** | 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 checking that suburb and zip/postcode match). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)) | ✓ | ✓ | ✓ | 20 | | **5.1.5** | Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content. | ✓ | ✓ | ✓ | 601 | -## V5.2 Sanitization and Sandboxing Requirements +## V5.2 Sanitization and Sandboxing | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | @@ -37,7 +37,7 @@ Properly implemented input validation controls, using positive allow lists and s | **5.2.7** | Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject. | ✓ | ✓ | ✓ | 159 | | **5.2.8** | Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. | ✓ | ✓ | ✓ | 94 | -## V5.3 Output Encoding and Injection Prevention Requirements +## V5.3 Output Encoding and Injection Prevention Output encoding close or adjacent to the interpreter in use is critical to the security of any application. Typically, output encoding is not persisted, but used to render the output safe in the appropriate output context for immediate use. Failing to output encode will result in an insecure, injectable, and unsafe application. @@ -58,7 +58,7 @@ Note: Using parameterized queries or escaping SQL is not always sufficient; tabl Note: The SVG format explicitly allows ECMA script in almost all contexts, so it may not be possible to block all SVG XSS vectors completely. If SVG upload is required, we strongly recommend either serving these uploaded files as text/plain or using a separate user supplied content domain to prevent successful XSS from taking over the application. -## V5.4 Memory, String, and Unmanaged Code Requirements +## V5.4 Memory, String, and Unmanaged Code The following requirements will only apply when the application uses a systems language or unmanaged code. @@ -68,7 +68,7 @@ The following requirements will only apply when the application uses a systems l | **5.4.2** | Verify that format strings do not take potentially hostile input, and are constant. | | ✓ | ✓ | 134 | | **5.4.3** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | | ✓ | ✓ | 190 | -## V5.5 Deserialization Prevention Requirements +## V5.5 Deserialization Prevention | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | diff --git a/4.0/en/0x14-V6-Cryptography.md b/4.0/en/0x14-V6-Cryptography.md index 9bf97a8255..78e5c46b5d 100644 --- a/4.0/en/0x14-V6-Cryptography.md +++ b/4.0/en/0x14-V6-Cryptography.md @@ -1,4 +1,4 @@ -# V6: Stored Cryptography Verification Requirements +# V6 Stored Cryptography ## Control Objective diff --git a/4.0/en/0x15-V7-Error-Logging.md b/4.0/en/0x15-V7-Error-Logging.md index a014e32031..c7ead18afc 100644 --- a/4.0/en/0x15-V7-Error-Logging.md +++ b/4.0/en/0x15-V7-Error-Logging.md @@ -1,4 +1,4 @@ -# V7: Error Handling and Logging Verification Requirements +# V7 Error Handling and Logging ## Control Objective @@ -14,7 +14,7 @@ If logs contain private or sensitive data, the definition of which varies from c It is also important to ensure that the application fails securely and that errors do not disclose unnecessary information. -## V7.1 Log Content Requirements +## V7.1 Log Content Logging sensitive information is dangerous - the logs become classified themselves, which means they need to be encrypted, become subject to retention policies, and must be disclosed in security audits. Ensure only necessary information is kept in logs, and certainly no payment, credentials (including session tokens), sensitive or personally identifiable information. @@ -30,7 +30,7 @@ V7.1 covers OWASP Top 10 2017:A10. As 2017:A10 and this section are not penetrat | **7.1.3** | Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 778 | | **7.1.4** | Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 778 | -## V7.2 Log Processing Requirements +## V7.2 Log Processing Timely logging is critical for audit events, triage, and escalation. Ensure that the application's logs are clear and can be easily monitored and analyzed either locally or log shipped to a remote monitoring system. @@ -44,7 +44,7 @@ V7.2 covers OWASP Top 10 2017:A10. As 2017:A10 and this section are not penetrat | **7.2.1** | Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. | | ✓ | ✓ | 778 | | **7.2.2** | Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations. | | ✓ | ✓ | 285 | -## V7.3 Log Protection Requirements +## V7.3 Log Protection Logs that can be trivially modified or deleted are useless for investigations and prosecutions. Disclosure of logs can expose inner details about the application or the data it contains. Care must be taken when protecting logs from unauthorized disclosure, modification or deletion. diff --git a/4.0/en/0x16-V8-Data-Protection.md b/4.0/en/0x16-V8-Data-Protection.md index 4393dd1607..0edcbc8bad 100644 --- a/4.0/en/0x16-V8-Data-Protection.md +++ b/4.0/en/0x16-V8-Data-Protection.md @@ -1,4 +1,4 @@ -# V8: Data Protection Verification Requirements +# V8 Data Protection ## Control Objective diff --git a/4.0/en/0x17-V9-Communications.md b/4.0/en/0x17-V9-Communications.md index 40001e9378..e4514c8d83 100644 --- a/4.0/en/0x17-V9-Communications.md +++ b/4.0/en/0x17-V9-Communications.md @@ -1,4 +1,4 @@ -# V9: Communications Verification Requirements +# V9 Communications ## Control Objective @@ -11,7 +11,7 @@ Ensure that a verified application satisfies the following high level requiremen Leading industry advice on secure TLS configuration changes frequently, often due to catastrophic breaks in existing algorithms and ciphers. Always use the most recent versions of TLS configuration review tools (such as SSLyze or other TLS scanners) to configure the preferred order and algorithm selection. Configuration should be periodically checked to ensure that secure communications configuration is always present and effective. -## V9.1 Client Communications Security Requirements +## V9.1 Client Communications Security All client communications should only take place over encrypted communication paths. In particular, the use of TLS 1.2 or later is essentially all but required by modern browsers and search engines. Configuration should be regularly reviewed using online tools to ensure that the latest leading practices are in place. @@ -21,7 +21,7 @@ All client communications should only take place over encrypted communication pa | **9.1.2** | Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred. | ✓ | ✓ | ✓ | 326 | | **9.1.3** | Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite. | ✓ | ✓ | ✓ | 326 | -## V9.2 Server Communications Security Requirements +## V9.2 Server Communications Security Server communications are more than just HTTP. Secure connections to and from other systems, such as monitoring systems, management tools, remote access and ssh, middleware, database, mainframes, partner or external source systems — must be in place. All of these must be encrypted to prevent "hard on the outside, trivially easy to intercept on the inside". diff --git a/4.0/en/0x18-V10-Malicious.md b/4.0/en/0x18-V10-Malicious.md index b3a4d5264d..f10503365f 100644 --- a/4.0/en/0x18-V10-Malicious.md +++ b/4.0/en/0x18-V10-Malicious.md @@ -1,4 +1,4 @@ -# V10: Malicious Code Verification Requirements +# V10 Malicious Code ## Control Objective @@ -11,7 +11,7 @@ Ensure that code satisfies the following high level requirements: Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality. -## V10.1 Code Integrity Controls +## V10.1 Code Integrity The best defense against malicious code is "trust, but verify". Introducing unauthorized or malicious code into code is often a criminal offence in many jurisdictions. Policies and procedures should make sanctions regarding malicious code clear. @@ -36,7 +36,7 @@ Complying with this section is not possible without complete access to source co | **10.2.5** | Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. | | | ✓ | 511 | | **10.2.6** | Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality. | | | ✓ | 507 | -## V10.3 Deployed Application Integrity Controls +## V10.3 Application Integrity Once an application is deployed, malicious code can still be inserted. Applications need to protect themselves against common attacks, such as executing unsigned code from untrusted sources and subdomain takeovers. diff --git a/4.0/en/0x19-V11-BusLogic.md b/4.0/en/0x19-V11-BusLogic.md index 3af3af02ad..a514f9d13b 100644 --- a/4.0/en/0x19-V11-BusLogic.md +++ b/4.0/en/0x19-V11-BusLogic.md @@ -1,4 +1,4 @@ -# V11: Business Logic Verification Requirements +# V11 Business Logic ## Control Objective @@ -8,7 +8,7 @@ Ensure that a verified application satisfies the following high level requiremen * Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on. * High value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks. -## V11.1 Business Logic Security Requirements +## V11.1 Business Logic Security Business logic security is so individual to every application that no one checklist will ever apply. Business logic security must be designed in to protect against likely external threats - it cannot be added using web application firewalls or secure communications. We recommend the use of threat modeling during design sprints, for example using the OWASP Cornucopia or similar tools. diff --git a/4.0/en/0x20-V12-Files-Resources.md b/4.0/en/0x20-V12-Files-Resources.md index 380af3adcd..d36d2d4492 100644 --- a/4.0/en/0x20-V12-Files-Resources.md +++ b/4.0/en/0x20-V12-Files-Resources.md @@ -1,4 +1,4 @@ -# V12: File and Resources Verification Requirements +# V12 File and Resources ## Control Objective @@ -7,7 +7,7 @@ Ensure that a verified application satisfies the following high level requiremen * Untrusted file data should be handled accordingly and in a secure manner. * Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions. -## V12.1 File Upload Requirements +## V12.1 File Upload Although zip bombs are eminently testable using penetration testing techniques, they are considered L2 and above to encourage design and development consideration with careful manual testing, and to avoid automated or unskilled manual penetration testing of a denial of service condition. @@ -17,13 +17,13 @@ Although zip bombs are eminently testable using penetration testing techniques, | **12.1.2** | Verify that compressed files are checked for "zip bombs" - small input files that will decompress into huge files thus exhausting file storage limits. | | ✓ | ✓ | 409 | | **12.1.3** | Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files. | | ✓ | ✓ | 770 | -## V12.2 File Integrity Requirements +## V12.2 File Integrity | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **12.2.1** | Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content. | | ✓ | ✓ | 434 | -## V12.3 File Execution Requirements +## V12.3 File Execution | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | @@ -34,21 +34,21 @@ Although zip bombs are eminently testable using penetration testing techniques, | **12.3.5** | Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection. | ✓ | ✓ | ✓ | 78 | | **12.3.6** | Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs. | | ✓ | ✓ | 829 | -## V12.4 File Storage Requirements +## V12.4 File Storage | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **12.4.1** | Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation. | ✓ | ✓ | ✓ | 922 | | **12.4.2** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content. | ✓ | ✓ | ✓ | 509 | -## V12.5 File Download Requirements +## V12.5 File Download | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | | **12.5.1** | Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required. | ✓ | ✓ | ✓ | 552 | | **12.5.2** | Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content. | ✓ | ✓ | ✓ | 434 | -## V12.6 SSRF Protection Requirements +## V12.6 SSRF Protection | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | diff --git a/4.0/en/0x21-V13-API.md b/4.0/en/0x21-V13-API.md index 92c7e44731..4b6ec0f5ca 100644 --- a/4.0/en/0x21-V13-API.md +++ b/4.0/en/0x21-V13-API.md @@ -1,4 +1,4 @@ -# V13: API and Web Service Verification Requirements +# V13 API and Web Service ## Control Objective @@ -10,7 +10,7 @@ Ensure that a verified application that uses trusted service layer APIs (commonl Please read this chapter in combination with all other chapters at this same level; we no longer duplicate authentication or API session management concerns. -## V13.1 Generic Web Service Security Verification Requirements +## V13.1 Generic Web Service Security | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | @@ -20,7 +20,7 @@ Please read this chapter in combination with all other chapters at this same lev | **13.1.4** | Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions. | | ✓ | ✓ | 285 | | **13.1.5** | Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type). | | ✓ | ✓ | 434 | -## V13.2 RESTful Web Service Verification Requirements +## V13.2 RESTful Web Service JSON schema validation is in a draft stage of standardization (see references). When considering using JSON schema validation, which is best practice for RESTful web services, consider using these additional data validation strategies in combination with JSON schema validation: @@ -39,7 +39,7 @@ Once the JSON schema validation standard is formalized, ASVS will update its adv | **13.2.5** | Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. | | ✓ | ✓ | 436 | | **13.2.6** | Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits. | | ✓ | ✓ | 345 | -## V13.3 SOAP Web Service Verification Requirements +## V13.3 SOAP Web Service | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | @@ -48,7 +48,7 @@ Once the JSON schema validation standard is formalized, ASVS will update its adv Note: Due to issues with XXE attacks against DTDs, DTD validation should not be used, and framework DTD evaluation disabled as per the requirements set out in V14 Configuration. -## V13.4 GraphQL and other Web Service Data Layer Security Requirements +## V13.4 GraphQL | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---:| :---: | :---: | diff --git a/4.0/en/0x22-V14-Config.md b/4.0/en/0x22-V14-Config.md index 7f8d66ea9e..27003b894b 100644 --- a/4.0/en/0x22-V14-Config.md +++ b/4.0/en/0x22-V14-Config.md @@ -1,4 +1,4 @@ -# V14: Configuration Verification Requirements +# V14 Configuration ## Control Objective @@ -10,7 +10,7 @@ Ensure that a verified application has: Configuration of the application out of the box should be safe to be on the Internet, which means a safe out of the box configuration. -## V14.1 Build +## V14.1 Build and Deploy Build pipelines are the basis for repeatable security - every time something insecure is discovered, it can be resolved in the source code, build or deployment scripts, and tested automatically. We are strongly encouraging the use of build pipelines with automatic security and dependency checks that warn or break the build to prevent known security issues being deployed into production. Manual steps performed irregularly directly leads to avoidable security mistakes. @@ -43,7 +43,7 @@ Note: At Level 1, 14.2.1 compliance relates to observations or detections of cli | **14.2.5** | Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | | | **14.2.6** | Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 265 | -## V14.3 Unintended Security Disclosure Requirements +## V14.3 Unintended Security Disclosure Configurations for production should be hardened to protect against common attacks, such as debug consoles, raise the bar for Cross-site Scripting (XSS) and Remote File Inclusion (RFI) attacks, and to eliminate trivial information discovery "vulnerabilities" that are the unwelcome hallmark of many penetration testing reports. Many of these issues are rarely rated as a significant risk, but they are chained together with other vulnerabilities. If these issues are not present by default, it raises the bar before most attacks can succeed. @@ -53,7 +53,7 @@ Configurations for production should be hardened to protect against common attac | **14.3.2** | Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures. | ✓ | ✓ | ✓ | 497 | | **14.3.3** | Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components. | ✓ | ✓ | ✓ | 200 | -## V14.4 HTTP Security Headers Requirements +## V14.4 HTTP Security Headers | # | Description | L1 | L2 | L3 | CWE | | --- | --- | --- | --- | -- | -- | @@ -65,7 +65,7 @@ Configurations for production should be hardened to protect against common attac | **14.4.6** | Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin". | ✓ | ✓ | ✓ | 116 | | **14.4.7** | Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers. | ✓ | ✓ | ✓ | 346 | -## V14.5 Validate HTTP Request Header Requirements +## V14.5 HTTP Request Header Validation | # | Description | L1 | L2 | L3 | CWE | | --- | --- | --- | --- | -- | -- |