From ca6174067e55f61cdc0554efa27a85150c9faa41 Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Sun, 2 Feb 2025 10:58:53 +0200 Subject: [PATCH] #2560 - level column to numeric --- 5.0/en/0x10-V1-Architecture.md | 18 +- 5.0/en/0x11-V2-Authentication.md | 202 +++++++++--------- 5.0/en/0x12-V3-Session-management.md | 106 ++++----- 5.0/en/0x12-V4-Access-Control.md | 64 +++--- ...x13-V5-Validation-Sanitization-Encoding.md | 122 +++++------ 5.0/en/0x14-V6-Cryptography.md | 110 +++++----- 5.0/en/0x15-V7-Error-Logging.md | 74 +++---- 5.0/en/0x16-V8-Data-Protection.md | 64 +++--- 5.0/en/0x17-V9-Communications.md | 60 +++--- 5.0/en/0x18-V10-Coding.md | 96 ++++----- 5.0/en/0x19-V11-BusLogic.md | 60 +++--- 5.0/en/0x20-V12-Files-Resources.md | 80 +++---- 5.0/en/0x21-V13-API.md | 86 ++++---- 5.0/en/0x22-V14-Config.md | 134 ++++++------ 5.0/en/0x50-V50-Web-Frontend-Security.md | 90 ++++---- 5.0/en/0x51-V51-OAuth2.md | 94 ++++---- 5.0/en/0x52-V52-Tokens.md | 20 +- 5.0/en/0x53-V53-WebRTC.md | 36 ++-- 18 files changed, 758 insertions(+), 758 deletions(-) diff --git a/5.0/en/0x10-V1-Architecture.md b/5.0/en/0x10-V1-Architecture.md index 79cce75a18..bf19a1f9c4 100644 --- a/5.0/en/0x10-V1-Architecture.md +++ b/5.0/en/0x10-V1-Architecture.md @@ -8,15 +8,15 @@ Note that the documentation requirements here are a temporary solution, and it i ## V1.1 Secure Software Development Lifecycle -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.1.1** | [DELETED, NOT IN SCOPE] | | | | | -| **1.1.2** | [DELETED, NOT IN SCOPE] | | | | | -| **1.1.3** | [DELETED, NOT IN SCOPE] | | | | | -| **1.1.4** | [DELETED, NOT IN SCOPE] | | | | | -| **1.1.5** | [MOVED TO 1.14.7] | | | | | -| **1.1.6** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **1.1.7** | [DELETED, NOT IN SCOPE] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.1.1** | [DELETED, NOT IN SCOPE] | | | +| **1.1.2** | [DELETED, NOT IN SCOPE] | | | +| **1.1.3** | [DELETED, NOT IN SCOPE] | | | +| **1.1.4** | [DELETED, NOT IN SCOPE] | | | +| **1.1.5** | [MOVED TO 1.14.7] | | | +| **1.1.6** | [DELETED, INSUFFICIENT IMPACT] | | | +| **1.1.7** | [DELETED, NOT IN SCOPE] | | | ## References diff --git a/5.0/en/0x11-V2-Authentication.md b/5.0/en/0x11-V2-Authentication.md index 1dde583a83..cf564e6756 100644 --- a/5.0/en/0x11-V2-Authentication.md +++ b/5.0/en/0x11-V2-Authentication.md @@ -22,14 +22,14 @@ We strongly urge US government agencies to review and implement NIST SP 800-63 i When designing authentication systems, the strength of hardware-enabled multi-factor authentication becomes irrelevant if an attacker can easily reset an account by calling a call center and answering commonly known questions. To ensure secure identity verification, all authentication pathways must possess equivalent strength. --> -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.2.1** | [MOVED TO 14.6.2] | | | | | -| **1.2.2** | [DELETED, MERGED TO 14.7.1] | | | | | -| **1.2.3** | [DELETED, COVERED BY 1.2.4] | | | | | -| **1.2.4** | [MODIFIED, SPLIT TO 2.2.11, COVERS 1.2.3] Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which should be consistently enforced across them. | | ✓ | ✓ | 306 | -| **1.2.5** | [ADDED] Verify that a list of context specific words are documented in order to prevent their use in passwords. | | ✓ | ✓ | 521 | -| **1.2.6** | [ADDED, SPLIT FROM 2.2.1] Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation should make clear how these controls are configured and prevent malicious account lockout. | ✓ | ✓ | ✓ | 307 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.2.1** | [MOVED TO 14.6.2] | | | +| **1.2.2** | [DELETED, MERGED TO 14.7.1] | | | +| **1.2.3** | [DELETED, COVERED BY 1.2.4] | | | +| **1.2.4** | [MODIFIED, SPLIT TO 2.2.11, COVERS 1.2.3] Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which should be consistently enforced across them. | 2 | 306 | +| **1.2.5** | [ADDED] Verify that a list of context specific words are documented in order to prevent their use in passwords. | 2 | 521 | +| **1.2.6** | [ADDED, SPLIT FROM 2.2.1] Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation should make clear how these controls are configured and prevent malicious account lockout. | 1 | 307 | ## V2.1 Password Security @@ -41,22 +41,22 @@ Credential Service Providers (CSPs) provide federated identity for users. Users The requirements in this section mostly relate to section [5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.1.1** | [MODIFIED] Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended. | ✓ | ✓ | ✓ | 521 | -| **2.1.2** | [MODIFIED] Verify that passwords of at least 64 characters are permitted. | ✓ | ✓ | ✓ | 521 | -| **2.1.3** | [MODIFIED] Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation. | ✓ | ✓ | ✓ | | -| **2.1.4** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **2.1.5** | [GRAMMAR] Verify that users can change their password. | ✓ | ✓ | ✓ | 620 | -| **2.1.6** | Verify that password change functionality requires the user's current and new password. | ✓ | ✓ | ✓ | 620 | -| **2.1.7** | [MODIFIED, SPLIT TO 2.1.13] Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords. | ✓ | ✓ | ✓ | 521 | -| **2.1.8** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **2.1.9** | 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. | ✓ | ✓ | ✓ | 521 | -| **2.1.10** | [MODIFIED, LEVEL L1 > L2] Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | | ✓ | ✓ | | -| **2.1.11** | Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | ✓ | ✓ | ✓ | 521 | -| **2.1.12** | [MODIFIED] Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password. | ✓ | ✓ | ✓ | 549 | -| **2.1.13** | [ADDED, SPLIT FROM 2.1.7, LEVEL L1 > L3] Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | | | ✓ | | -| **2.1.14** | [ADDED] Verify that the documented list of context specific words is used to prevent easy to guess passwords being created. | | ✓ | ✓ | 521 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.1.1** | [MODIFIED] Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended. | 1 | 521 | +| **2.1.2** | [MODIFIED] Verify that passwords of at least 64 characters are permitted. | 1 | 521 | +| **2.1.3** | [MODIFIED] Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation. | 1 | | +| **2.1.4** | [DELETED, INSUFFICIENT IMPACT] | | | +| **2.1.5** | [GRAMMAR] Verify that users can change their password. | 1 | 620 | +| **2.1.6** | Verify that password change functionality requires the user's current and new password. | 1 | 620 | +| **2.1.7** | [MODIFIED, SPLIT TO 2.1.13] Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords. | 1 | 521 | +| **2.1.8** | [DELETED, INSUFFICIENT IMPACT] | | | +| **2.1.9** | 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. | 1 | 521 | +| **2.1.10** | [MODIFIED, LEVEL L1 > L2] Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | 2 | | +| **2.1.11** | Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | 1 | 521 | +| **2.1.12** | [MODIFIED] Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password. | 1 | 549 | +| **2.1.13** | [ADDED, SPLIT FROM 2.1.7, LEVEL L1 > L3] Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | 3 | | +| **2.1.14** | [ADDED] Verify that the documented list of context specific words is used to prevent easy to guess passwords being created. | 2 | 521 | Possible sources of frequently used passwords for requirement 2.1.7 include: @@ -73,19 +73,19 @@ NIST SP 800-63 considers email as [not acceptable](https://pages.nist.gov/800-63 The requirements in this section relate to a variety of sections of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html), including: 4.2.1, 4.3.1, 5.2.2, and 6.1.2. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.2.1** | [MODIFIED, SPLIT TO 1.2.6] Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation. | ✓ | ✓ | ✓ | 307 | -| **2.2.2** | [MODIFIED] Verify that email is not used as either a single-factor or multi-factor authentication mechanism. | ✓ | ✓ | ✓ | 304 | -| **2.2.3** | [MODIFIED, SPLIT TO 2.2.10, COVERS 2.5.5] Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address. | ✓ | ✓ | ✓ | 778 | -| **2.2.4** | [MODIFIED, SPLIT TO 2.2.9, MERGED FROM 2.2.7, 2.3.2] Verify that a hardware-based authentication mechanism is supported that provides impersonation resistance against phishing attacks (such as WebAuthn) and verifies intent to authenticate by requiring a user-initiated action (such as a button press on a FIDO hardware key). | | | ✓ | 308 | -| **2.2.5** | [MOVED TO 9.3.3] | | | | | -| **2.2.6** | [DELETED, COVERED BY 2.7.3, 2.8.4] | | | | | -| **2.2.7** | [DELETED, MERGED TO 2.2.4] | | | | | -| **2.2.8** | [ADDED] Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality should also have this protection. | | | ✓ | | -| **2.2.9** | [ADDED, SPLIT FROM 2.2.4] Verify that the application requires users to either use a multi-factor authentication mechanism or a requires a combination of single-factor authentication mechanisms. | | ✓ | ✓ | 308 | -| **2.2.10** | [ADDED, SPLIT FROM 2.2.3] Verify that users are notified of suspicious authentication attempts. This may include successful or unsuccessful authentication from an unusual location or client, partially successful authentication with only one of multiple factors, successful or unsuccessful authentication after a long period of inactivity or successful authentication after several unsuccessful attempts. | | ✓ | ✓ | 778 | -| **2.2.11** | [ADDED, SPLIT FROM 1.2.4] Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | | ✓ | ✓ | 306 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.2.1** | [MODIFIED, SPLIT TO 1.2.6] Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation. | 1 | 307 | +| **2.2.2** | [MODIFIED] Verify that email is not used as either a single-factor or multi-factor authentication mechanism. | 1 | 304 | +| **2.2.3** | [MODIFIED, SPLIT TO 2.2.10, COVERS 2.5.5] Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address. | 1 | 778 | +| **2.2.4** | [MODIFIED, SPLIT TO 2.2.9, MERGED FROM 2.2.7, 2.3.2] Verify that a hardware-based authentication mechanism is supported that provides impersonation resistance against phishing attacks (such as WebAuthn) and verifies intent to authenticate by requiring a user-initiated action (such as a button press on a FIDO hardware key). | 3 | 308 | +| **2.2.5** | [MOVED TO 9.3.3] | | | +| **2.2.6** | [DELETED, COVERED BY 2.7.3, 2.8.4] | | | +| **2.2.7** | [DELETED, MERGED TO 2.2.4] | | | +| **2.2.8** | [ADDED] Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality should also have this protection. | 3 | | +| **2.2.9** | [ADDED, SPLIT FROM 2.2.4] Verify that the application requires users to either use a multi-factor authentication mechanism or a requires a combination of single-factor authentication mechanisms. | 2 | 308 | +| **2.2.10** | [ADDED, SPLIT FROM 2.2.3] Verify that users are notified of suspicious authentication attempts. This may include successful or unsuccessful authentication from an unusual location or client, partially successful authentication with only one of multiple factors, successful or unsuccessful authentication after a long period of inactivity or successful authentication after several unsuccessful attempts. | 2 | 778 | +| **2.2.11** | [ADDED, SPLIT FROM 1.2.4] Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | 2 | 306 | ## V2.3 Authentication Factor Lifecycle @@ -93,12 +93,12 @@ Authentication mechanisms can involve passwords, soft tokens, hardware tokens, a Note: Passwords are not to have a maximum lifetime or be subject to password rotation. Passwords should be checked for being breached, not regularly replaced. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.3.1** | [MODIFIED] Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password. | ✓ | ✓ | ✓ | 330 | -| **2.3.2** | [DELETED, MERGED TO 2.2.4] | | | | | -| **2.3.3** | [MODIFIED] Verify that renewal instructions for authentication mechanisms which expire are sent with enough time to be carried out before the old authentication mechanism expires, configuring automated reminders if necessary. | | ✓ | ✓ | 287 | -| **2.3.4** | [ADDED] Verify that administrative users can initiate the password reset process for the user, but that this does not allow them to change or choose the user's password. This prevents a situation where they know the user's password. | ✓ | ✓ | ✓ | 620 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.3.1** | [MODIFIED] Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password. | 1 | 330 | +| **2.3.2** | [DELETED, MERGED TO 2.2.4] | | | +| **2.3.3** | [MODIFIED] Verify that renewal instructions for authentication mechanisms which expire are sent with enough time to be carried out before the old authentication mechanism expires, configuring automated reminders if necessary. | 2 | 287 | +| **2.3.4** | [ADDED] Verify that administrative users can initiate the password reset process for the user, but that this does not allow them to change or choose the user's password. This prevents a situation where they know the user's password. | 1 | 620 | ## V2.4 Credential Storage @@ -108,27 +108,27 @@ The current list of approved password hashing algorithms is detailed in NIST SP In particular, note that since these algorithms are intentionally compute-intensive, there have been cases in the past where providing a very long password leads to a denial of service condition. It is therefore very important to protect against this. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.4.1** | [MOVED TO 6.6.2] | | | | | -| **2.4.2** | [DELETED, INCORRECT] | | | | | -| **2.4.3** | [DELETED, MERGED TO 6.6.2] | | | | | -| **2.4.4** | [DELETED, MERGED TO 6.6.2] | | | | | -| **2.4.5** | [DELETED, INCORRECT] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.4.1** | [MOVED TO 6.6.2] | | | +| **2.4.2** | [DELETED, INCORRECT] | | | +| **2.4.3** | [DELETED, MERGED TO 6.6.2] | | | +| **2.4.4** | [DELETED, MERGED TO 6.6.2] | | | +| **2.4.5** | [DELETED, INCORRECT] | | | ## V2.5 Credential Recovery The requirements in this section mostly relate to section [5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) or [6.1.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#replacement) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.5.1** | [DELETED, INCORRECT] | | | | | -| **2.5.2** | [GRAMMAR] Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present. | ✓ | ✓ | ✓ | 640 | -| **2.5.3** | [DELETED, COVERED BY 6.6.2] | | | | | -| **2.5.4** | [MOVED TO 14.1.10] | | | | | -| **2.5.5** | [DELETED, COVERED BY 2.2.3] | | | | | -| **2.5.6** | [MODIFIED] Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi-factor authentication mechanisms. | ✓ | ✓ | ✓ | 640 | -| **2.5.7** | [GRAMMAR, LEVEL L2 > L1] Verify that if OTP or other multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment. | ✓ | ✓ | ✓ | 308 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.5.1** | [DELETED, INCORRECT] | | | +| **2.5.2** | [GRAMMAR] Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present. | 1 | 640 | +| **2.5.3** | [DELETED, COVERED BY 6.6.2] | | | +| **2.5.4** | [MOVED TO 14.1.10] | | | +| **2.5.5** | [DELETED, COVERED BY 2.2.3] | | | +| **2.5.6** | [MODIFIED] Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi-factor authentication mechanisms. | 1 | 640 | +| **2.5.7** | [GRAMMAR, LEVEL L2 > L1] Verify that if OTP or other multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment. | 1 | 308 | ## V2.6 Lookup Secrets @@ -136,12 +136,12 @@ Lookup secrets are pre-generated lists of secret codes, similar to Transaction A The requirements in this section mostly relate to section [5.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-512-look-up-secrets) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.6.1** | Verify that lookup secrets can be used only once. | | ✓ | ✓ | 308 | -| **2.6.2** | [MODIFIED, SPLIT TO 2.6.4] Verify that, when being stored in the application's back-end, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more. | | ✓ | ✓ | 330 | -| **2.6.3** | [MODIFIED] Verify that lookup secrets are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values. | | ✓ | ✓ | 310 | -| **2.6.4** | [ADDED, SPLIT FROM 2.6.2] Verify that lookup secrets have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | | ✓ | ✓ | 330 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.6.1** | Verify that lookup secrets can be used only once. | 2 | 308 | +| **2.6.2** | [MODIFIED, SPLIT TO 2.6.4] Verify that, when being stored in the application's back-end, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more. | 2 | 330 | +| **2.6.3** | [MODIFIED] Verify that lookup secrets are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values. | 2 | 310 | +| **2.6.4** | [ADDED, SPLIT FROM 2.6.2] Verify that lookup secrets have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | 2 | 330 | ## V2.7 Out-of-Band authentication mechanisms @@ -157,16 +157,16 @@ Unsafe out-of-band authentication mechanisms such as e-mail and VOIP are not per The requirements in this section mostly relate to section [5.1.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-513-out-of-band-devices) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.7.1** | [MODIFIED] Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered only when alternate stronger methods (such as push notifications) are also offered and when the service provides information on their security risks to users. | ✓ | ✓ | ✓ | 287 | -| **2.7.2** | [MODIFIED] Verify that out-of-band authentication requests, codes, or tokens expire within 10 minutes. | ✓ | ✓ | ✓ | 287 | -| **2.7.3** | [GRAMMAR, COVERS 2.2.6] Verify that out-of-band authentication requests, codes, or tokens are only usable once, and only for the original authentication request. | ✓ | ✓ | ✓ | 287 | -| **2.7.4** | [GRAMMAR] Verify that the secondary communications channel being used is secure and independent of the primary channel. | ✓ | ✓ | ✓ | 523 | -| **2.7.5** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **2.7.6** | [MODIFIED] Verify that codes used in out-of-band authentication are generated using a cryptographically secure random number generator (CSPRNG) and contain at least 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | | ✓ | ✓ | 310 | -| **2.7.7** | [ADDED] Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using either rate limiting or a code with at least 64 bits of entropy. | | ✓ | ✓ | 307 | -| **2.7.8** | [ADDED] Verify that, where push notifications are used for multi-factor authentication, rate limiting or number matching is used to prevent push bombing attacks. | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.7.1** | [MODIFIED] Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered only when alternate stronger methods (such as push notifications) are also offered and when the service provides information on their security risks to users. | 1 | 287 | +| **2.7.2** | [MODIFIED] Verify that out-of-band authentication requests, codes, or tokens expire within 10 minutes. | 1 | 287 | +| **2.7.3** | [GRAMMAR, COVERS 2.2.6] Verify that out-of-band authentication requests, codes, or tokens are only usable once, and only for the original authentication request. | 1 | 287 | +| **2.7.4** | [GRAMMAR] Verify that the secondary communications channel being used is secure and independent of the primary channel. | 1 | 523 | +| **2.7.5** | [DELETED, INSUFFICIENT IMPACT] | | | +| **2.7.6** | [MODIFIED] Verify that codes used in out-of-band authentication are generated using a cryptographically secure random number generator (CSPRNG) and contain at least 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | 2 | 310 | +| **2.7.7** | [ADDED] Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using either rate limiting or a code with at least 64 bits of entropy. | 2 | 307 | +| **2.7.8** | [ADDED] Verify that, where push notifications are used for multi-factor authentication, rate limiting or number matching is used to prevent push bombing attacks. | 3 | | ## V2.8 Time based One-time Passwords @@ -176,16 +176,16 @@ Multi-factor TOTPs are similar to single-factor TOTPs, but require a valid PIN c The requirements in this section relate to a variety of sections of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html), including: 5.1.4.2, 5.1.5.2, 5.2.1, and 5.2.3. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.8.1** | [GRAMMAR] Verify that time-based, one-time passwords have a defined lifetime before expiring. | ✓ | ✓ | ✓ | 613 | -| **2.8.2** | [GRAMMAR] Verify that symmetric keys used to verify submitted time-based, one-time passwords are highly protected, such as by using a hardware security module or secure operating system based key storage. | | ✓ | ✓ | 320 | -| **2.8.3** | [GRAMMAR] Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of time-based, one-time passwords. | | ✓ | ✓ | 326 | -| **2.8.4** | [GRAMMAR, COVERS 2.2.6] Verify that a time-based, one-time password can be used only once within the validity period. | | ✓ | ✓ | 287 | -| **2.8.5** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **2.8.6** | [MODIFIED, LEVEL L2 > L3] Verify that physical single-factor OTP generators can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location. | | | ✓ | 613 | -| **2.8.7** | [MODIFIED, LEVEL L2 > L3] Verify that biometric authentication mechanisms are only used as secondary factors together with either something you have or something you know. | | | ✓ | 308 | -| **2.8.8** | [ADDED] Verify that time-based OTPs are checked based on a time source from a trusted service and not from an untrusted or client provided time. | | | ✓ | 367 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.8.1** | [GRAMMAR] Verify that time-based, one-time passwords have a defined lifetime before expiring. | 1 | 613 | +| **2.8.2** | [GRAMMAR] Verify that symmetric keys used to verify submitted time-based, one-time passwords are highly protected, such as by using a hardware security module or secure operating system based key storage. | 2 | 320 | +| **2.8.3** | [GRAMMAR] Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of time-based, one-time passwords. | 2 | 326 | +| **2.8.4** | [GRAMMAR, COVERS 2.2.6] Verify that a time-based, one-time password can be used only once within the validity period. | 2 | 287 | +| **2.8.5** | [DELETED, INSUFFICIENT IMPACT] | | | +| **2.8.6** | [MODIFIED, LEVEL L2 > L3] Verify that physical single-factor OTP generators can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location. | 3 | 613 | +| **2.8.7** | [MODIFIED, LEVEL L2 > L3] Verify that biometric authentication mechanisms are only used as secondary factors together with either something you have or something you know. | 3 | 308 | +| **2.8.8** | [ADDED] Verify that time-based OTPs are checked based on a time source from a trusted service and not from an untrusted or client provided time. | 3 | 367 | ## V2.9 Cryptographic authentication mechanism @@ -195,28 +195,28 @@ The requirements for single-factor cryptographic devices and software, and multi The requirements in this section mostly relate to section [5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.9.1** | [MODIFIED, LEVEL L2 > L3] Verify that the authentication verifier stores the cryptographic keys used in verification such that they are protected against modification (and for symmetric keys, against disclosure). This could involve using a Trusted Platform Module (TPM), a Hardware Security Module (HSM), or an OS service that can provide this secure storage. | | | ✓ | 320 | -| **2.9.2** | [LEVEL L2 > L3] 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 | -| **2.9.3** | [MODIFIED, LEVEL L2 > L3] Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of the cryptographic keys. | | | ✓ | 327 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.9.1** | [MODIFIED, LEVEL L2 > L3] Verify that the authentication verifier stores the cryptographic keys used in verification such that they are protected against modification (and for symmetric keys, against disclosure). This could involve using a Trusted Platform Module (TPM), a Hardware Security Module (HSM), or an OS service that can provide this secure storage. | 3 | 320 | +| **2.9.2** | [LEVEL L2 > L3] Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. | 3 | 330 | +| **2.9.3** | [MODIFIED, LEVEL L2 > L3] Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of the cryptographic keys. | 3 | 327 | ## V2.10 Service Authentication -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.10.1** | [MOVED TO 14.7.1] | | | | | -| **2.10.2** | [MOVED TO 14.7.2] | | | | | -| **2.10.3** | [DELETED, COVERED BY 14.8.1] | | | | | -| **2.10.4** | [DELETED, MERGED TO 14.8.1] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.10.1** | [MOVED TO 14.7.1] | | | +| **2.10.2** | [MOVED TO 14.7.2] | | | +| **2.10.3** | [DELETED, COVERED BY 14.8.1] | | | +| **2.10.4** | [DELETED, MERGED TO 14.8.1] | | | ## V2.11 Authentication with an Identity Providers -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **2.11.1** | [ADDED] Verify that, if the application supports multiple identity providers (IDPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). Usually, the application should register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IDP. | | ✓ | ✓ | | -| **2.11.2** | [ADDED] Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, rejecting any assertions that are unsigned or have invalid signatures. | | ✓ | ✓ | | -| **2.11.3** | [ADDED] Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **2.11.1** | [ADDED] Verify that, if the application supports multiple identity providers (IDPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). Usually, the application should register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IDP. | 2 | | +| **2.11.2** | [ADDED] Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, rejecting any assertions that are unsigned or have invalid signatures. | 2 | | +| **2.11.3** | [ADDED] Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks. | 2 | | ## References diff --git a/5.0/en/0x12-V3-Session-management.md b/5.0/en/0x12-V3-Session-management.md index ef9835df6b..1c7ffe186c 100644 --- a/5.0/en/0x12-V3-Session-management.md +++ b/5.0/en/0x12-V3-Session-management.md @@ -18,81 +18,81 @@ Note that requirements for specific implementation details of certain session ma There is no single pattern that suits all applications. Therefore, it is infeasible to define universal boundaries and limits that suit all cases. A risk analysis with documented security decisions related to session handling must be conducted as a prerequisite to implementation and testing. This ensures that the session management system is tailored to the specific requirements of the application. Regardless of whether a stateful or "stateless" session mechanism is chosen, the analysis must be complete and documented to demonstrate that the selected solution is capable of satisfying all relevant security requirements. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.3.1** | [ADDED] Verify that the user's session inactivity period and maximum session lifetime before reauthentication are documented, appropriate in combination with other controls, and that documentation includes justification for any deviations from NIST SP 800-63B reauthentication requirements. | ✓ | ✓ | ✓ | | -| **1.3.2** | [ADDED] Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviours and actions to be taken when the maximum number of active sessions is reached. | ✓ | ✓ | ✓ | | -| **1.3.3** | [ADDED] Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other condition that should require re-authentication. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.3.1** | [ADDED] Verify that the user's session inactivity period and maximum session lifetime before reauthentication are documented, appropriate in combination with other controls, and that documentation includes justification for any deviations from NIST SP 800-63B reauthentication requirements. | 1 | | +| **1.3.2** | [ADDED] Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviours and actions to be taken when the maximum number of active sessions is reached. | 1 | | +| **1.3.3** | [ADDED] Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other condition that should require re-authentication. | 1 | | ## V3.1 Fundamental Session Management Security This section satisfies the essential requirements of secure sessions by verifying that session tokens are securely generated, managed, and validated. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.1.1** | [DELETED, MERGED TO 8.3.1] | | | | | -| **3.1.2** | [ADDED] Verify that the application performs all session token verification using a trusted, back-end service. | ✓ | ✓ | ✓ | 603 | -| **3.1.3** | [MODIFIED, MOVED FROM 3.5.2, LEVEL L2 > L1] Verify that the application uses either self-contained or reference tokens for session management. Static API secrets and keys should be avoided. | ✓ | ✓ | ✓ | 798 | -| **3.1.4** | [MODIFIED, MOVED FROM 3.2.2, MERGED FROM 3.2.4] Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy. | ✓ | ✓ | ✓ | | -| **3.1.5** | [MODIFIED, MOVED FROM 3.2.1] Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.1.1** | [DELETED, MERGED TO 8.3.1] | | | +| **3.1.2** | [ADDED] Verify that the application performs all session token verification using a trusted, back-end service. | 1 | 603 | +| **3.1.3** | [MODIFIED, MOVED FROM 3.5.2, LEVEL L2 > L1] Verify that the application uses either self-contained or reference tokens for session management. Static API secrets and keys should be avoided. | 1 | 798 | +| **3.1.4** | [MODIFIED, MOVED FROM 3.2.2, MERGED FROM 3.2.4] Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy. | 1 | | +| **3.1.5** | [MODIFIED, MOVED FROM 3.2.1] Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. | 1 | | ## V3.2 Session Binding -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.2.1** | [MOVED TO 3.1.5] | | | | | -| **3.2.2** | [MOVED TO 3.1.4] | | | | | -| **3.2.3** | [DELETED, MERGED TO 8.2.2] | | | | | -| **3.2.4** | [DELETED, MERGED TO 3.1.4] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.2.1** | [MOVED TO 3.1.5] | | | +| **3.2.2** | [MOVED TO 3.1.4] | | | +| **3.2.3** | [DELETED, MERGED TO 8.2.2] | | | +| **3.2.4** | [DELETED, MERGED TO 3.1.4] | | | ## V3.3 Session Timeout Session timeout mechanisms serve to minimize the window of opportunity for session hijacking and other forms of session abuse. Timeouts must satisfy documented requirements. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.3.1** | [MOVED TO 3.8.1] | | | | | -| **3.3.2** | [MODIFIED, SPLIT TO 3.3.5] Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions. | ✓ | ✓ | ✓ | | -| **3.3.3** | [MOVED TO 3.8.2] | | | | | -| **3.3.4** | [MOVED TO 3.7.2] | | | | | -| **3.3.5** | [ADDED, SPLIT FROM 3.3.2] Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions. | ✓ | ✓ | ✓ | 613 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.3.1** | [MOVED TO 3.8.1] | | | +| **3.3.2** | [MODIFIED, SPLIT TO 3.3.5] Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions. | 1 | | +| **3.3.3** | [MOVED TO 3.8.2] | | | +| **3.3.4** | [MOVED TO 3.7.2] | | | +| **3.3.5** | [ADDED, SPLIT FROM 3.3.2] Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions. | 1 | 613 | ## V3.4 Cookie-based Session Management -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.4.1** | [MOVED TO 50.2.1] | | | | | -| **3.4.2** | [MOVED TO 50.2.2] | | | | | -| **3.4.3** | [MOVED TO 50.2.3] | | | | | -| **3.4.4** | [MOVED TO 50.2.4] | | | | | -| **3.4.5** | [DELETED, DEPRECATED BY 50.1.1] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.4.1** | [MOVED TO 50.2.1] | | | +| **3.4.2** | [MOVED TO 50.2.2] | | | +| **3.4.3** | [MOVED TO 50.2.3] | | | +| **3.4.4** | [MOVED TO 50.2.4] | | | +| **3.4.5** | [DELETED, DEPRECATED BY 50.1.1] | | | ## V3.5 Token-based Session Management -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.5.1** | [MOVED TO 51.4.14] | | | | | -| **3.5.2** | [MOVED TO 3.1.3] | | | | | -| **3.5.3** | [MOVED TO 52.1.1] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.5.1** | [MOVED TO 51.4.14] | | | +| **3.5.2** | [MOVED TO 3.1.3] | | | +| **3.5.3** | [MOVED TO 52.1.1] | | | ## V3.6 Federated Re-authentication This section relates to those writing Relying Party (RP) or Credential Service Provider (CSP) code. These requirements are derived from the [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) for Federation & Assertions. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.6.1** | [MODIFIED, MERGED FROM 3.6.2] Verify that session lifetime and termination between Relying Parties (RPs) and Credential Service Providers (CSPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between CSP authentication events is reached. | | | ✓ | 613 | -| **3.6.2** | [DELETED, MERGED TO 3.6.1] | | | | | -| **3.6.3** | [ADDED] Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.6.1** | [MODIFIED, MERGED FROM 3.6.2] Verify that session lifetime and termination between Relying Parties (RPs) and Credential Service Providers (CSPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between CSP authentication events is reached. | 3 | 613 | +| **3.6.2** | [DELETED, MERGED TO 3.6.1] | | | +| **3.6.3** | [ADDED] Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction. | 2 | | ## V3.7 Defenses Against Session Abuse This section provides requirements to mitigate the risk posed by active sessions that are either hijacked or abused through vectors such as cross-site request forgery (CSRF) and other cross-site attacks, which rely on the existence and capabilities of active user sessions. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.7.1** | [MODIFIED] Verify that the application requires re-authentication or secondary verification before allowing highly sensitive transactions or modifications to sensitive account attributes such as authentication settings. | ✓ | ✓ | ✓ | 306 | -| **3.7.2** | [MODIFIED, MOVED FROM 3.3.4] Verify that users are able to view and (having re-entered login credentials) terminate any or all currently active sessions. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.7.1** | [MODIFIED] Verify that the application requires re-authentication or secondary verification before allowing highly sensitive transactions or modifications to sensitive account attributes such as authentication settings. | 1 | 306 | +| **3.7.2** | [MODIFIED, MOVED FROM 3.3.4] Verify that users are able to view and (having re-entered login credentials) terminate any or all currently active sessions. | 2 | | ## V3.8 Session Termination @@ -102,13 +102,13 @@ Session termination should result in requiring re-authentication and be effectiv For stateful session mechanisms, termination typically involves invalidating the session on the backend. In the case of self-contained tokens, additional measures are required to revoke or block these tokens, as they may otherwise remain valid until expiration. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **3.8.1** | [MODIFIED, MOVED FROM 3.3.1] Verify that logout and expiration terminate the user's session, such that the back button or a downstream relying party cannot resume an authenticated session. | ✓ | ✓ | ✓ | 613 | -| **3.8.2** | [MODIFIED, MOVED FROM 3.3.3, LEVEL L2 > L1] Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (including password change via reset or recovery and, if present, an MFA settings update). | ✓ | ✓ | ✓ | 613 | -| **3.8.3** | [ADDED] Verify that all pages that require authentication have easy and visible access to logout functionality. | | ✓ | ✓ | | -| **3.8.4** | [ADDED] Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company). | ✓ | ✓ | ✓ | 613 | -| **3.8.5** | [ADDED] Verify that application administrators are able to terminate active sessions for an individual user or for all users. | ✓ | ✓ | ✓ | 613 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **3.8.1** | [MODIFIED, MOVED FROM 3.3.1] Verify that logout and expiration terminate the user's session, such that the back button or a downstream relying party cannot resume an authenticated session. | 1 | 613 | +| **3.8.2** | [MODIFIED, MOVED FROM 3.3.3, LEVEL L2 > L1] Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (including password change via reset or recovery and, if present, an MFA settings update). | 1 | 613 | +| **3.8.3** | [ADDED] Verify that all pages that require authentication have easy and visible access to logout functionality. | 2 | | +| **3.8.4** | [ADDED] Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company). | 1 | 613 | +| **3.8.5** | [ADDED] Verify that application administrators are able to terminate active sessions for an individual user or for all users. | 1 | 613 | ## References diff --git a/5.0/en/0x12-V4-Access-Control.md b/5.0/en/0x12-V4-Access-Control.md index c4a699ebed..5d99bed9b7 100644 --- a/5.0/en/0x12-V4-Access-Control.md +++ b/5.0/en/0x12-V4-Access-Control.md @@ -11,53 +11,53 @@ Authorization is the process of allowing access only to permitted consumers (use Comprehensive access control documentation is essential to ensure that security decisions are consistently applied, auditable, and aligned with organizational policies, reducing the risk of unauthorized access by making security requirements clear and actionable for developers, administrators, and testers. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.4.1** | [DELETED, COVERED BY 4.2.3] | | | | | -| **1.4.2** | [DELETED] | | | | | -| **1.4.3** | [DELETED] | | | | | -| **1.4.4** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **1.4.5** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **1.4.6** | [ADDED] Verify that access control documentation defines controls that incorporate changes to a consumers environmental and contextual attributes (such as time of day, location, IP address, or device) to make security decisions, including those pertaining to authentication and authorization. These changes should be detected both when the consumer tries to start a new session or during an existing session. | | | ✓ | | -| **1.4.7** | [ADDED] Verify that access control documentation defines explicit rules for restricting function-level, data-specific, and field-level access based on consumer permissions, specifying relevant consumer and resource attributes, as well as environmental factors involved in decision-making. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.4.1** | [DELETED, COVERED BY 4.2.3] | | | +| **1.4.2** | [DELETED] | | | +| **1.4.3** | [DELETED] | | | +| **1.4.4** | [DELETED, INSUFFICIENT IMPACT] | | | +| **1.4.5** | [DELETED, INSUFFICIENT IMPACT] | | | +| **1.4.6** | [ADDED] Verify that access control documentation defines controls that incorporate changes to a consumers environmental and contextual attributes (such as time of day, location, IP address, or device) to make security decisions, including those pertaining to authentication and authorization. These changes should be detected both when the consumer tries to start a new session or during an existing session. | 3 | | +| **1.4.7** | [ADDED] Verify that access control documentation defines explicit rules for restricting function-level, data-specific, and field-level access based on consumer permissions, specifying relevant consumer and resource attributes, as well as environmental factors involved in decision-making. | 1 | | ## V4.1 General Access Control Design Implementing granular access controls at the function, data, and field levels will ensure that consumers can only access what has been explicitly granted to them. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **4.1.1** | [MOVED TO 4.2.3] | | | | | -| **4.1.2** | [DELETED, COVERED BY 4.1.3] | | | | | -| **4.1.3** | [MODIFIED, COVERS 4.1.2] Verify that the application ensures that function-level access is restricted to consumers with explicit permissions. | ✓ | ✓ | ✓ | 285 | -| **4.1.4** | [DELETED] | | | | | -| **4.1.5** | [MOVED TO 7.4.5] | | | | | -| **4.1.6** | [MODIFIED, MOVED FROM 4.2.1, COVERS 13.1.4] Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA). | ✓ | ✓ | ✓ | 639 | -| **4.1.7** | [ADDED] Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA). | | ✓ | ✓ | 283 | -| **4.1.8** | [ADDED] Verify that adaptive security controls related to authentication and authorization decisions based on a consumers environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented as defined in access control documentation. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **4.1.1** | [MOVED TO 4.2.3] | | | +| **4.1.2** | [DELETED, COVERED BY 4.1.3] | | | +| **4.1.3** | [MODIFIED, COVERS 4.1.2] Verify that the application ensures that function-level access is restricted to consumers with explicit permissions. | 1 | 285 | +| **4.1.4** | [DELETED] | | | +| **4.1.5** | [MOVED TO 7.4.5] | | | +| **4.1.6** | [MODIFIED, MOVED FROM 4.2.1, COVERS 13.1.4] Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA). | 1 | 639 | +| **4.1.7** | [ADDED] Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA). | 2 | 283 | +| **4.1.8** | [ADDED] Verify that adaptive security controls related to authentication and authorization decisions based on a consumers environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented as defined in access control documentation. | 2 | | ## V4.2 Operation Level Access Control The immediate application of access control changes in the appropriate tier of an application's architecture is crucial to preventing unauthorized actions, especially in dynamic environments. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **4.2.1** | [MOVED TO 4.1.6] | | | | | -| **4.2.2** | [MOVED TO 50.4.1] | | | | | -| **4.2.3** | [MODIFIED, MOVED FROM 4.1.1, COVERS 1.4.1, 14.5.2] Verify that the application enforces access control rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript. | ✓ | ✓ | ✓ | 602 | -| **4.2.4** | [ADDED] Verify that changes to values on which access control decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they should no longer be able to do so and revert the change. Note that this would be unable to mitigate information leakage. | | ✓ | ✓ | | -| **4.2.5** | [ADDED] Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service should use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions. | | | ✓ | 441 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **4.2.1** | [MOVED TO 4.1.6] | | | +| **4.2.2** | [MOVED TO 50.4.1] | | | +| **4.2.3** | [MODIFIED, MOVED FROM 4.1.1, COVERS 1.4.1, 14.5.2] Verify that the application enforces access control rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript. | 1 | 602 | +| **4.2.4** | [ADDED] Verify that changes to values on which access control decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they should no longer be able to do so and revert the change. Note that this would be unable to mitigate information leakage. | 2 | | +| **4.2.5** | [ADDED] Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service should use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions. | 3 | 441 | ## V4.3 Other Access Control Considerations Additional considerations for access control, particularly for administrative interfaces and multi-tenant environments, will help prevent unauthorized access. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **4.3.1** | [MODIFIED, LEVEL L1 > L3] Verify that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis, ensuring that network location or trusted endpoints are not the sole factors for authorization even though they may reduce the likelihood of unauthorized access. | | | ✓ | 419 | -| **4.3.2** | [SPLIT TO 14.3.4, 14.3.5] | | | | | -| **4.3.3** | [MOVED TO 14.7.3] | | | | | -| **4.3.4** | [ADDED] Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact. | ✓ | ✓ | ✓ | 283 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **4.3.1** | [MODIFIED, LEVEL L1 > L3] Verify that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis, ensuring that network location or trusted endpoints are not the sole factors for authorization even though they may reduce the likelihood of unauthorized access. | 3 | 419 | +| **4.3.2** | [SPLIT TO 14.3.4, 14.3.5] | | | +| **4.3.3** | [MOVED TO 14.7.3] | | | +| **4.3.4** | [ADDED] Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact. | 1 | 283 | ## References diff --git a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md index 2efaaba3e2..43a6e7f69f 100644 --- a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -16,12 +16,12 @@ In 4.0, we moved away from the term "server-side" as a loaded trust boundary ter The "untrusted client" term here refers to client-side technologies that render the presentation layer, commonly referred to as 'front-end' technologies. The term 'serialization' in this context refers not only to transmitting data over the wire, such as an array of values or processing a JSON structure but also to the handling of complex objects that may contain logic. --> -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.5.1** | [SPLIT TO 1.11.5, 1.11.6] | | | | | -| **1.5.2** | [DELETED, MERGED TO 5.5.3] | | | | | -| **1.5.3** | [MOVED TO 11.3.4] | | | | | -| **1.5.4** | [MOVED TO 5.6.2] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.5.1** | [SPLIT TO 1.11.5, 1.11.6] | | | +| **1.5.2** | [DELETED, MERGED TO 5.5.3] | | | +| **1.5.3** | [MOVED TO 11.3.4] | | | +| **1.5.4** | [MOVED TO 5.6.2] | | | ## V5.1 Input Validation @@ -31,14 +31,14 @@ Properly implemented input validation controls, using positive allowlists and st Input validation provides valuable hygiene for the application in making sure that data is received in the correct format and should be applied to all inputs where possible. However, it does not remove or replace the need to use correct encoding, escaping, or sanitization when using the data for next component or for presenting it for output. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **5.1.1** | [MOVED TO 10.4.7] | | | | | -| **5.1.2** | [MOVED TO 10.4.4] | | | | | -| **5.1.3** | [MOVED TO 11.3.1] | | | | | -| **5.1.4** | [SPLIT TO 11.3.2, 11.3.3] | | | | | -| **5.1.5** | [MODIFIED, SPLIT TO 50.8.1] Verify that the application will only automatically redirect the user to a different URL directly from an application URL where the destination appears on an allowlist. | ✓ | ✓ | ✓ | 601 | -| **5.1.6** | [ADDED] Verify that the application validates that user-controlled input in HTTP request header fields does not exceed the server's maximum header field size limit (usually 4kB or 8kB) to prevent client-based denial of service attacks. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **5.1.1** | [MOVED TO 10.4.7] | | | +| **5.1.2** | [MOVED TO 10.4.4] | | | +| **5.1.3** | [MOVED TO 11.3.1] | | | +| **5.1.4** | [SPLIT TO 11.3.2, 11.3.3] | | | +| **5.1.5** | [MODIFIED, SPLIT TO 50.8.1] Verify that the application will only automatically redirect the user to a different URL directly from an application URL where the destination appears on an allowlist. | 1 | 601 | +| **5.1.6** | [ADDED] Verify that the application validates that user-controlled input in HTTP request header fields does not exceed the server's maximum header field size limit (usually 4kB or 8kB) to prevent client-based denial of service attacks. | 2 | | ## V5.2 Sanitization and Sandboxing @@ -46,21 +46,21 @@ The ideal protection against using untrusted content in an unsafe context is usi Where it is not possible to do this, other options include sanitization and sandboxing. Sanitization will involve removing potentially dangerous characters or content which in some cases could change the semantic meaning of the input but for security reasons there may be no choice. Sandboxing may involve ensuring that a potentially dangerous operation is contained such that even if it suffers a security vulnerability, that will not endanger the wider application. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **5.2.1** | [MODIFIED] Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized using a well-known and secure HTML sanitization library or framework feature. | ✓ | ✓ | ✓ | 116 | -| **5.2.2** | [MODIFIED] Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long. | ✓ | ✓ | ✓ | 138 | -| **5.2.3** | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | ✓ | ✓ | ✓ | 147 | -| **5.2.4** | [MODIFIED, COVERS 5.5.4] Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. | ✓ | ✓ | ✓ | 95 | -| **5.2.5** | [MODIFIED] Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated. | ✓ | ✓ | ✓ | 94 | -| **5.2.6** | [MODIFIED] Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service. | ✓ | ✓ | ✓ | 918 | -| **5.2.7** | [MODIFIED] Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, e.g., do not contain 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 | -| **5.2.9** | [ADDED] Verify that the application uses slashes to correctly escape special characters being used in regular expressions to ensure they are not misinterpreted as control characters. | ✓ | ✓ | ✓ | 624 | -| **5.2.10** | [ADDED] Verify that regular expressions are free from elements causing exponential backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway Regex attacks. | ✓ | ✓ | ✓ | 1333 | -| **5.2.11** | [ADDED] Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured as securely as possible to prevent JNDI injection attacks. | ✓ | ✓ | ✓ | 917 | -| **5.2.12** | [ADDED] Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks. | | ✓ | ✓ | | -| **5.2.13** | [MODIFIED, MOVED FROM 5.4.2] Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed. | | ✓ | ✓ | 134 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **5.2.1** | [MODIFIED] Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized using a well-known and secure HTML sanitization library or framework feature. | 1 | 116 | +| **5.2.2** | [MODIFIED] Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long. | 1 | 138 | +| **5.2.3** | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | 1 | 147 | +| **5.2.4** | [MODIFIED, COVERS 5.5.4] Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. | 1 | 95 | +| **5.2.5** | [MODIFIED] Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated. | 1 | 94 | +| **5.2.6** | [MODIFIED] Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service. | 1 | 918 | +| **5.2.7** | [MODIFIED] Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, e.g., do not contain scripts and foreignObject. | 1 | 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. | 1 | 94 | +| **5.2.9** | [ADDED] Verify that the application uses slashes to correctly escape special characters being used in regular expressions to ensure they are not misinterpreted as control characters. | 1 | 624 | +| **5.2.10** | [ADDED] Verify that regular expressions are free from elements causing exponential backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway Regex attacks. | 1 | 1333 | +| **5.2.11** | [ADDED] Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured as securely as possible to prevent JNDI injection attacks. | 1 | 917 | +| **5.2.12** | [ADDED] Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks. | 2 | | +| **5.2.13** | [MODIFIED, MOVED FROM 5.4.2] Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed. | 2 | 134 | 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. @@ -70,21 +70,21 @@ Output encoding or escaping close or adjacent to a potentially dangerous context In many cases, software libraries will include safe or safer functions which will do this automatically although it will be necessary to be sure that they are correct for the current context. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **5.3.1** | [MODIFIED, SPLIT TO 5.3.13] Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure. | ✓ | ✓ | ✓ | 116 | -| **5.3.2** | [DELETED, COVERED BY 13.1.7] | | | | | -| **5.3.3** | [MODIFIED, SPLIT TO 50.6.2, COVERS 5.3.6] Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | ✓ | ✓ | ✓ | | -| **5.3.4** | [MODIFIED, COVERS 5.3.5] Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This should also be considered when writing stored procedures. | ✓ | ✓ | ✓ | 89 | -| **5.3.5** | [DELETED, COVERED BY 5.3.4] | | | | | -| **5.3.6** | [DELETED, COVERED BY 5.3.3] | | | | | -| **5.3.7** | Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. | ✓ | ✓ | ✓ | 90 | -| **5.3.8** | [COVERS 12.3.5] 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. | ✓ | ✓ | ✓ | 78 | -| **5.3.9** | [DELETED, MERGED TO 12.3.1] | | | | | -| **5.3.10** | [MODIFIED] Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries. | ✓ | ✓ | ✓ | 643 | -| **5.3.11** | [ADDED] Verify that the application is protected against CSV and Formula Injection. The application should follow the escaping rules defined in RFC4180 2.6 and 2.7 when exporting CSV files. The application should escape special characters including '=', '+', '-', '@' '\t' (tab) and '\00' (null character) using a single quote, if they are the first character in a field, when exporting CSV files and other spreadsheet formats such as xls, xlsx, odf. | ✓ | ✓ | ✓ | 1236 | -| **5.3.12** | [ADDED] Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks. | | ✓ | ✓ | | -| **5.3.13** | [ADDED, SPLIT FROM 5.3.1] Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:). | ✓ | ✓ | ✓ | 116 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **5.3.1** | [MODIFIED, SPLIT TO 5.3.13] Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure. | 1 | 116 | +| **5.3.2** | [DELETED, COVERED BY 13.1.7] | | | +| **5.3.3** | [MODIFIED, SPLIT TO 50.6.2, COVERS 5.3.6] Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | 1 | | +| **5.3.4** | [MODIFIED, COVERS 5.3.5] Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This should also be considered when writing stored procedures. | 1 | 89 | +| **5.3.5** | [DELETED, COVERED BY 5.3.4] | | | +| **5.3.6** | [DELETED, COVERED BY 5.3.3] | | | +| **5.3.7** | Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. | 1 | 90 | +| **5.3.8** | [COVERS 12.3.5] 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. | 1 | 78 | +| **5.3.9** | [DELETED, MERGED TO 12.3.1] | | | +| **5.3.10** | [MODIFIED] Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries. | 1 | 643 | +| **5.3.11** | [ADDED] Verify that the application is protected against CSV and Formula Injection. The application should follow the escaping rules defined in RFC4180 2.6 and 2.7 when exporting CSV files. The application should escape special characters including '=', '+', '-', '@' '\t' (tab) and '\00' (null character) using a single quote, if they are the first character in a field, when exporting CSV files and other spreadsheet formats such as xls, xlsx, odf. | 1 | 1236 | +| **5.3.12** | [ADDED] Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks. | 2 | | +| **5.3.13** | [ADDED, SPLIT FROM 5.3.1] Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:). | 1 | 116 | Note: Using parameterized queries or escaping SQL is not always sufficient; table and column names, ORDER BY and so on, cannot be escaped. The inclusion of escaped user-supplied data in these fields results in failed queries or SQL injection. @@ -92,24 +92,24 @@ Note: Using parameterized queries or escaping SQL is not always sufficient; tabl The following requirements will only apply when the application uses a systems language or unmanaged code. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **5.4.1** | Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. | | ✓ | ✓ | 120 | -| **5.4.2** | [MOVED TO 5.2.13] | | | | | -| **5.4.3** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | | ✓ | ✓ | 190 | -| **5.4.4** | [ADDED] Verify that dynamically allocated memory and resources are properly released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities. | | ✓ | ✓ | 416 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **5.4.1** | Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. | 2 | 120 | +| **5.4.2** | [MOVED TO 5.2.13] | | | +| **5.4.3** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | 2 | 190 | +| **5.4.4** | [ADDED] Verify that dynamically allocated memory and resources are properly released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities. | 2 | 416 | ## V5.5 Safe Deserialization Conversion of data from some sort of stored or transmitted representation into actual application objects (deserialization) has historically been the cause of a variety of code injection vulnerabilities. It is important to perform this process carefully and safely to avoid these types of issues. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **5.5.1** | [DELETED, INCORRECT] | | | | | -| **5.5.2** | Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. | ✓ | ✓ | ✓ | 611 | -| **5.5.3** | [MODIFIED, MERGED FROM 1.5.2] Verify that deserialization with untrusted clients enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure (such as BinaryFormatter) must not be used with untrusted input. | ✓ | ✓ | ✓ | 502 | -| **5.5.4** | [DELETED, COVERED BY 5.2.4] | | | | | -| **5.5.5** | [MODIFIED, MOVED FROM 13.1.1, LEVEL L1 > L2] Verify that different parsers used in the application for the same data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a consistent way and use the same character encoding mechanism to avoid issues such as JSON Interoperability vulnerabilities or different URI or file parsing behavior being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. | | ✓ | ✓ | 436 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **5.5.1** | [DELETED, INCORRECT] | | | +| **5.5.2** | Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. | 1 | 611 | +| **5.5.3** | [MODIFIED, MERGED FROM 1.5.2] Verify that deserialization with untrusted clients enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure (such as BinaryFormatter) must not be used with untrusted input. | 1 | 502 | +| **5.5.4** | [DELETED, COVERED BY 5.2.4] | | | +| **5.5.5** | [MODIFIED, MOVED FROM 13.1.1, LEVEL L1 > L2] Verify that different parsers used in the application for the same data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a consistent way and use the same character encoding mechanism to avoid issues such as JSON Interoperability vulnerabilities or different URI or file parsing behavior being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. | 2 | 436 | ## V5.6 Validation and Sanitization Architecture @@ -128,10 +128,10 @@ The requirement does not belong here, if it is: reorg: move it to 1st chapter in the paragraph --> -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **5.6.1** | [ADDED] Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization. | ✓ | ✓ | ✓ | 174 | -| **5.6.2** | [MODIFIED, MOVED FROM 1.5.4] Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by the interpreter itself. | | ✓ | ✓ | 116 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **5.6.1** | [ADDED] Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization. | 1 | 174 | +| **5.6.2** | [MODIFIED, MOVED FROM 1.5.4] Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by the interpreter itself. | 2 | 116 | ## References diff --git a/5.0/en/0x14-V6-Cryptography.md b/5.0/en/0x14-V6-Cryptography.md index dd07201c78..49259b7e1d 100644 --- a/5.0/en/0x14-V6-Cryptography.md +++ b/5.0/en/0x14-V6-Cryptography.md @@ -25,21 +25,21 @@ It is also important to ensure that all cryptographic assets, such as algorithms * [CryptoMon - Network Cryptography Monitor - using eBPF, written in python](https://github.com/Santandersecurityresearch/CryptoMon) * [Cryptobom Forge Tool: Generating Comprehensive CBOMs from CodeQL Outputs](https://github.com/Santandersecurityresearch/cryptobom-forge) -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.6.1** | Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57. | | ✓ | ✓ | 320 | -| **1.6.2** | [DELETED, MERGED TO 14.8.1] | | | | | -| **1.6.3** | [DELETED, MERGED TO 6.2.4] | | | | | -| **1.6.4** | [MODIFIED] Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It should also document where keys can and cannot be used in the system and also the types of data which can and cannot be protected using the keys. | | ✓ | ✓ | 320 | -| **1.6.5** | [ADDED] Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations. | | | ✓ | 320 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.6.1** | Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57. | 2 | 320 | +| **1.6.2** | [DELETED, MERGED TO 14.8.1] | | | +| **1.6.3** | [DELETED, MERGED TO 6.2.4] | | | +| **1.6.4** | [MODIFIED] Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It should also document where keys can and cannot be used in the system and also the types of data which can and cannot be protected using the keys. | 2 | 320 | +| **1.6.5** | [ADDED] Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations. | 3 | 320 | ## V6.1 Data Classification -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.1.1** | [DELETED, MERGED TO 1.8.1] | | | | | -| **6.1.2** | [DELETED, MERGED TO 1.8.1] | | | | | -| **6.1.3** | [DELETED, COVERED BY 1.8.1] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.1.1** | [DELETED, MERGED TO 1.8.1] | | | +| **6.1.2** | [DELETED, MERGED TO 1.8.1] | | | +| **6.1.3** | [DELETED, COVERED BY 1.8.1] | | | ## V6.2 Algorithms @@ -47,84 +47,84 @@ Recent advances in cryptography mean that previously safe algorithms and key len Although this section is not easily penetration tested, developers should consider this entire section as mandatory even though L1 is missing from most of the items. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.2.1** | [MODIFIED] Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | ✓ | ✓ | ✓ | 310 | -| **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | | ✓ | ✓ | 327 | -| **6.2.3** | [DELETED, COVERED BY 6.5.1, 6.5.2, 6.6.1] | | | | | -| **6.2.4** | [MODIFIED, MERGED FROM 1.6.3] Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available. | | ✓ | ✓ | 320 | -| **6.2.5** | [SPLIT TO 6.5.1, 6.5.2, 6.6.1] | | | | | -| **6.2.6** | [MOVED TO 6.5.3] | | | | | -| **6.2.7** | [MOVED TO 6.5.4] | | | | | -| **6.2.8** | Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | | | ✓ | 385 | -| **6.2.9** | [ADDED] Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security. | ✓ | ✓ | ✓ | 311 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.2.1** | [MODIFIED] Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | 1 | 310 | +| **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | 2 | 327 | +| **6.2.3** | [DELETED, COVERED BY 6.5.1, 6.5.2, 6.6.1] | | | +| **6.2.4** | [MODIFIED, MERGED FROM 1.6.3] Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available. | 2 | 320 | +| **6.2.5** | [SPLIT TO 6.5.1, 6.5.2, 6.6.1] | | | +| **6.2.6** | [MOVED TO 6.5.3] | | | +| **6.2.7** | [MOVED TO 6.5.4] | | | +| **6.2.8** | Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | 3 | 385 | +| **6.2.9** | [ADDED] Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security. | 1 | 311 | ## V6.3 Random Values Cryptographically secure Pseudo-random Number Generation (CSPRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.3.1** | [GRAMMAR, COVERS 6.3.2, LEVEL L2 > L1] Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically-secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition. | ✓ | ✓ | ✓ | 338 | -| **6.3.2** | [DELETED, COVERED BY 6.3.1] | | | | | -| **6.3.3** | [GRAMMAR, LEVEL L3 > L1] Verify that random number generation works properly under heavy system load, or that the system degrades gracefully. | ✓ | ✓ | ✓ | 338 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.3.1** | [GRAMMAR, COVERS 6.3.2, LEVEL L2 > L1] Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically-secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition. | 1 | 338 | +| **6.3.2** | [DELETED, COVERED BY 6.3.1] | | | +| **6.3.3** | [GRAMMAR, LEVEL L3 > L1] Verify that random number generation works properly under heavy system load, or that the system degrades gracefully. | 1 | 338 | ## V6.4 Secret Management Although this section is not easily penetration tested, developers should consider this entire section as mandatory even though L1 is missing from most of the items. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.4.1** | [MOVED TO 14.8.1] | | | | | -| **6.4.2** | [MOVED TO 14.8.2] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.4.1** | [MOVED TO 14.8.1] | | | +| **6.4.2** | [MOVED TO 14.8.2] | | | ## V6.5 Encryption Algorithms Authenticated encryption algorithms built on AES and CHACHA20 form the backbone of modern cryptographic practice. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.5.1** | [ADDED, SPLIT FROM 6.2.5, COVERS 6.2.3] Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | | ✓ | ✓ | 326 | -| **6.5.2** | [ADDED, SPLIT FROM 6.2.5, COVERS 6.2.3, LEVEL L2 > L1] Verify that only secure, authenticated ciphers and modes such as AES with GCM are used. | ✓ | ✓ | ✓ | 326 | -| **6.5.3** | [MODIFIED, MOVED FROM 6.2.6, LEVEL L2 > L3] Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used. | | | ✓ | 326 | -| **6.5.4** | [MODIFIED, MOVED FROM 6.2.7] Verify that encrypted data is authenticated via signatures, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification. | | | ✓ | 326 | -| **6.5.5** | [ADDED] Verify that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode. | | | ✓ | 326 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.5.1** | [ADDED, SPLIT FROM 6.2.5, COVERS 6.2.3] Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | 2 | 326 | +| **6.5.2** | [ADDED, SPLIT FROM 6.2.5, COVERS 6.2.3, LEVEL L2 > L1] Verify that only secure, authenticated ciphers and modes such as AES with GCM are used. | 1 | 326 | +| **6.5.3** | [MODIFIED, MOVED FROM 6.2.6, LEVEL L2 > L3] Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used. | 3 | 326 | +| **6.5.4** | [MODIFIED, MOVED FROM 6.2.7] Verify that encrypted data is authenticated via signatures, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification. | 3 | 326 | +| **6.5.5** | [ADDED] Verify that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode. | 3 | 326 | ## V6.6 Hashing and Hash-based Functions Cryptographic hashes are used in a wide variety of cryptographic protocols, such as digital signatures, HMAC, key derivation functions (KDF), random bit generation, and password storage. The security of the cryptographic system is only as strong as the underlying hash functions used. This section outlines the requirements for using secure hash functions in cryptographic operations. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.6.1** | [ADDED, SPLIT FROM 6.2.5, COVERS 6.2.3] Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose. | | ✓ | ✓ | | -| **6.6.2** | [MODIFIED, MOVED FROM 2.4.1, MERGED FROM 2.4.3, 2.4.4, COVERS 2.5.3] Verify that passwords are stored using an approved, computationally intensive, hashing algorithm with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks more challenging. | | ✓ | ✓ | | -| **6.6.3** | [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or pre-image attacks. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.6.1** | [ADDED, SPLIT FROM 6.2.5, COVERS 6.2.3] Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose. | 2 | | +| **6.6.2** | [MODIFIED, MOVED FROM 2.4.1, MERGED FROM 2.4.3, 2.4.4, COVERS 2.5.3] Verify that passwords are stored using an approved, computationally intensive, hashing algorithm with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks more challenging. | 2 | | +| **6.6.3** | [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or pre-image attacks. | 1 | | ## V6.7 Key Exchange Mechanisms There exists a need for approved key exchange mechanisms, such as Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) to ensure that the cryptosystem remains secure against modern threats. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.7.1** | [ADDED] Verify that industry-proven cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This should prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.7.1** | [ADDED] Verify that industry-proven cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This should prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks. | 2 | | ## V6.8 In-Use Data Cryptography Protecting data while it is being processed is paramount. Techniques such as full memory encryption, encryption of data in transit, and ensuring data is encrypted as quickly as possible after use is recommended. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.8.1** | [ADDED] Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | | | ✓ | | -| **6.8.2** | [ADDED] Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.8.1** | [ADDED] Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | 3 | | +| **6.8.2** | [ADDED] Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | 2 | | ## V6.9 Post-Quantum Cryptography (PQC) The need to future-proof cryptographic systems in preparation for the eventual rise of quantum computing is critical. Post-Quantum Cryptography (PQC) focuses on developing cryptographic systems that are resistant to quantum attacks, which could break current encryption methods such as RSA and ECC. Please see the Appendix for the latest information on available PQC primitives. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **6.9.1** | [ADDED] Verify that a cryptographic inventory is maintained and includes a documented transformation plan or mapping that outlines the migration path from current cryptographic algorithms and systems to those that are post-quantum cryptography/quantum-safe. | | ✓ | ✓ | | -| **6.9.2** | [ADDED] Verify that advancements in the field of post-quantum cryptography are being monitored in order to ensure that the application is aligned with emerging industry standards, and remains prepared for quantum threats. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **6.9.1** | [ADDED] Verify that a cryptographic inventory is maintained and includes a documented transformation plan or mapping that outlines the migration path from current cryptographic algorithms and systems to those that are post-quantum cryptography/quantum-safe. | 2 | | +| **6.9.2** | [ADDED] Verify that advancements in the field of post-quantum cryptography are being monitored in order to ensure that the application is aligned with emerging industry standards, and remains prepared for quantum threats. | 2 | | ## References diff --git a/5.0/en/0x15-V7-Error-Logging.md b/5.0/en/0x15-V7-Error-Logging.md index 264ff49489..2460def296 100644 --- a/5.0/en/0x15-V7-Error-Logging.md +++ b/5.0/en/0x15-V7-Error-Logging.md @@ -12,11 +12,11 @@ Aside from this, it is also important to ensure that the application fails secur ## V1.7 Errors, Logging and Auditing Documentation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.7.1** | [MOVED TO 7.1.7] | | | | | -| **1.7.2** | [MOVED TO 7.3.5] | | | | | -| **1.7.3** | [ADDED] Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled and how long logs are kept for. | | ✓ | ✓ | 778 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.7.1** | [MOVED TO 7.1.7] | | | +| **1.7.2** | [MOVED TO 7.3.5] | | | +| **1.7.3** | [ADDED] Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled and how long logs are kept for. | 2 | 778 | ## V7.1 General Logging @@ -24,15 +24,15 @@ Logging sensitive information is dangerous - the logs become classified themselv For the specific information which should be included in a log entry, refer to external detailed guidance such as the OWASP Logging Cheat Sheet. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **7.1.1** | [MODIFIED, MERGED FROM 7.1.2] Verify that when logging sensitive data, the application considers the protection level of the data. For example, it may not be allowed to log certain data such as credentials or payment details. Other data such as session tokens may only be logged having been hashed or masked, either in full or partially. | ✓ | ✓ | ✓ | 532 | -| **7.1.2** | [DELETED, MERGED TO 7.1.1] | | | | | -| **7.1.3** | [MOVED TO 7.2.3] | | | | | -| **7.1.4** | [MODIFIED] Verify that each log entry includes necessary metadata that would allow for a detailed investigation of the timeline when an event happens. | | ✓ | ✓ | 778 | -| **7.1.5** | [MOVED FROM 7.3.4] Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. | | ✓ | ✓ | | -| **7.1.6** | [ADDED] Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory. | | ✓ | ✓ | | -| **7.1.7** | [MODIFIED, MOVED FROM 1.7.1] Verify that logs can be read and correlated by the log processor which is in use, preferably by using a common logging format. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **7.1.1** | [MODIFIED, MERGED FROM 7.1.2] Verify that when logging sensitive data, the application considers the protection level of the data. For example, it may not be allowed to log certain data such as credentials or payment details. Other data such as session tokens may only be logged having been hashed or masked, either in full or partially. | 1 | 532 | +| **7.1.2** | [DELETED, MERGED TO 7.1.1] | | | +| **7.1.3** | [MOVED TO 7.2.3] | | | +| **7.1.4** | [MODIFIED] Verify that each log entry includes necessary metadata that would allow for a detailed investigation of the timeline when an event happens. | 2 | 778 | +| **7.1.5** | [MOVED FROM 7.3.4] Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. | 2 | | +| **7.1.6** | [ADDED] Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory. | 2 | | +| **7.1.7** | [MODIFIED, MOVED FROM 1.7.1] Verify that logs can be read and correlated by the log processor which is in use, preferably by using a common logging format. | 2 | | ## V7.2 Security Events @@ -40,39 +40,39 @@ Logging events which are security relevant is an important mechanism for being a This section will briefly discuss the types of events to log but deliberately does not go into too much detail. It will be necessary to refer to external detailed guidance such as the OWASP Logging Cheat Sheet and the OWASP Application Logging Vocabulary Cheat Sheet for specific implementation details. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **7.2.1** | [MODIFIED] Verify that all authentication operations are logged including both successful and unsuccessful attempts. Additional metadata such as type of authentication or factors used should also be collected. | | ✓ | ✓ | 778 | -| **7.2.2** | [MODIFIED] Verify that all access control decisions are logged including failed attempts. | | ✓ | ✓ | 285 | -| **7.2.3** | [MODIFIED, MOVED FROM 7.1.3] Verify that the application logs attempts to bypass the security controls defined in the design documentation such as input validation. | | ✓ | ✓ | 778 | -| **7.2.4** | [MODIFIED, MOVED FROM 11.1.7] Verify that the application monitors for unusual events or activity from a business logic perspective. | | ✓ | ✓ | 754 | -| **7.2.5** | [MODIFIED, MOVED FROM 11.1.8] Verify that the application has configurable alerting when unusual or malicious activity is detected. | | ✓ | ✓ | 390 | -| **7.2.6** | [MODIFIED, MOVED FROM 9.2.5] Verify that the application logs security control failures such as backend TLS failures. | | | ✓ | 778 | -| **7.2.7** | [MODIFIED, MOVED FROM 8.3.5] Verify that accessing sensitive data is logged (without logging the sensitive data itself) if this is required by relevant data protection requirements. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **7.2.1** | [MODIFIED] Verify that all authentication operations are logged including both successful and unsuccessful attempts. Additional metadata such as type of authentication or factors used should also be collected. | 2 | 778 | +| **7.2.2** | [MODIFIED] Verify that all access control decisions are logged including failed attempts. | 2 | 285 | +| **7.2.3** | [MODIFIED, MOVED FROM 7.1.3] Verify that the application logs attempts to bypass the security controls defined in the design documentation such as input validation. | 2 | 778 | +| **7.2.4** | [MODIFIED, MOVED FROM 11.1.7] Verify that the application monitors for unusual events or activity from a business logic perspective. | 2 | 754 | +| **7.2.5** | [MODIFIED, MOVED FROM 11.1.8] Verify that the application has configurable alerting when unusual or malicious activity is detected. | 2 | 390 | +| **7.2.6** | [MODIFIED, MOVED FROM 9.2.5] Verify that the application logs security control failures such as backend TLS failures. | 3 | 778 | +| **7.2.7** | [MODIFIED, MOVED FROM 8.3.5] Verify that accessing sensitive data is logged (without logging the sensitive data itself) if this is required by relevant data protection requirements. | 2 | | ## 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. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **7.3.1** | Verify that all logging components appropriately encode data to prevent log injection. | | ✓ | ✓ | 117 | -| **7.3.2** | [DELETED] | | | | | -| **7.3.3** | [MODIFIED] Verify that logs are protected from unauthorized access and cannot be modified. | | ✓ | ✓ | 200 | -| **7.3.4** | [MOVED TO 7.1.5] | | | | | -| **7.3.5** | [MOVED FROM 1.7.2] Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **7.3.1** | Verify that all logging components appropriately encode data to prevent log injection. | 2 | 117 | +| **7.3.2** | [DELETED] | | | +| **7.3.3** | [MODIFIED] Verify that logs are protected from unauthorized access and cannot be modified. | 2 | 200 | +| **7.3.4** | [MOVED TO 7.1.5] | | | +| **7.3.5** | [MOVED FROM 1.7.2] Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. | 2 | | ## V7.4 Error Handling The purpose of error handling is to ensure the application fails gracefully and securely without disclosing sensitive information. The application should be written in a way that ensures this will always happen. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **7.4.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. | ✓ | ✓ | ✓ | 210 | -| **7.4.2** | [MODIFIED] Verify that a consistent and standardized exception handling mechanism (or a functional equivalent) is used across the codebase. | | ✓ | ✓ | 544 | -| **7.4.3** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. | | ✓ | ✓ | 431 | -| **7.4.4** | [ADDED] Verify that the application is designed in a way that a failure to access external resources does not result in the entire application failing, for example using the circuit breaker pattern. | | ✓ | ✓ | | -| **7.4.5** | [MODIFIED, MOVED FROM 4.1.5, LEVEL L1 > L2] Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail open conditions such as processing a transaction despite errors resulting from validation logic. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **7.4.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. | 1 | 210 | +| **7.4.2** | [MODIFIED] Verify that a consistent and standardized exception handling mechanism (or a functional equivalent) is used across the codebase. | 2 | 544 | +| **7.4.3** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. | 2 | 431 | +| **7.4.4** | [ADDED] Verify that the application is designed in a way that a failure to access external resources does not result in the entire application failing, for example using the circuit breaker pattern. | 2 | | +| **7.4.5** | [MODIFIED, MOVED FROM 4.1.5, LEVEL L1 > L2] Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail open conditions such as processing a transaction despite errors resulting from validation logic. | 2 | | Note: Certain languages, such as Swift and Go - and through common design practice - many functional languages, do not support exceptions or last-resort event handlers. In this case, architects and developers should use a pattern, language, or framework-friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events. diff --git a/5.0/en/0x16-V8-Data-Protection.md b/5.0/en/0x16-V8-Data-Protection.md index 9ef473fdd3..e4f6e72337 100644 --- a/5.0/en/0x16-V8-Data-Protection.md +++ b/5.0/en/0x16-V8-Data-Protection.md @@ -10,33 +10,33 @@ This chapter includes requirements related to defining what data needs to be pro ## V1.8 Data Protection and Privacy Documentation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.8.1** | [MODIFIED, MERGED FROM 8.3.4, 6.1.1, 6.1.2, COVERS 6.1.3] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data. Note that this includes sensitive data that is being encoded in a recoverable form such as Base64 and JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with. | | ✓ | ✓ | 213 | -| **1.8.2** | [MODIFIED, SPLIT TO 8.1.9, COVERS 8.3.7] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.8.1** | [MODIFIED, MERGED FROM 8.3.4, 6.1.1, 6.1.2, COVERS 6.1.3] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data. Note that this includes sensitive data that is being encoded in a recoverable form such as Base64 and JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with. | 2 | 213 | +| **1.8.2** | [MODIFIED, SPLIT TO 8.1.9, COVERS 8.3.7] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. | 2 | | ## V8.1 General Data Protection -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **8.1.1** | [MODIFIED, MERGED FROM 8.1.2] Verify that the application prevents sensitive data from being cached in server components such as load balancers and application caches or ensures that the data is securely purged after use. | | ✓ | ✓ | 524 | -| **8.1.2** | [DELETED, MERGED TO 8.1.1] | | | | | -| **8.1.3** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **8.1.4** | [GRAMMAR] Verify that the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application. | | ✓ | ✓ | 770 | -| **8.1.5** | [DELETED, NOT IN SCOPE] | | | | | -| **8.1.6** | [DELETED, NOT IN SCOPE] | | | | | -| **8.1.7** | [ADDED] Verify that caching mechanisms are configured to only cache responses which have the correct content type and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when an non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks. | | ✓ | ✓ | 444 | -| **8.1.8** | [ADDED] Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's control. | | ✓ | ✓ | 200 | -| **8.1.9** | [ADDED, SPLIT FROM 1.8.2] Verify that controls around sensitive data are implemented as defined in the documentation for the specific data's protection level. | | ✓ | ✓ | | -| **8.1.10** | [ADDED] Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the full data is absolutely required, it should be masked in the user interface unless the user specifically views it. | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **8.1.1** | [MODIFIED, MERGED FROM 8.1.2] Verify that the application prevents sensitive data from being cached in server components such as load balancers and application caches or ensures that the data is securely purged after use. | 2 | 524 | +| **8.1.2** | [DELETED, MERGED TO 8.1.1] | | | +| **8.1.3** | [DELETED, INSUFFICIENT IMPACT] | | | +| **8.1.4** | [GRAMMAR] Verify that the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application. | 2 | 770 | +| **8.1.5** | [DELETED, NOT IN SCOPE] | | | +| **8.1.6** | [DELETED, NOT IN SCOPE] | | | +| **8.1.7** | [ADDED] Verify that caching mechanisms are configured to only cache responses which have the correct content type and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when an non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks. | 2 | 444 | +| **8.1.8** | [ADDED] Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's control. | 2 | 200 | +| **8.1.9** | [ADDED, SPLIT FROM 1.8.2] Verify that controls around sensitive data are implemented as defined in the documentation for the specific data's protection level. | 2 | | +| **8.1.10** | [ADDED] Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the full data is absolutely required, it should be masked in the user interface unless the user specifically views it. | 3 | | ## V8.2 Client-side Data Protection -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **8.2.1** | [MODIFIED] Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in browsers. | ✓ | ✓ | ✓ | 525 | -| **8.2.2** | [MODIFIED, MERGED FROM 3.2.3] Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session identifiers. | ✓ | ✓ | ✓ | 922 | -| **8.2.3** | [MODIFIED] Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The "Clear-Site-Data header" may be able to help with this but the client-side should also be able to clear up if the server connection is lost. | ✓ | ✓ | ✓ | 922 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **8.2.1** | [MODIFIED] Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in browsers. | 1 | 525 | +| **8.2.2** | [MODIFIED, MERGED FROM 3.2.3] Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session identifiers. | 1 | 922 | +| **8.2.3** | [MODIFIED] Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The "Clear-Site-Data header" may be able to help with this but the client-side should also be able to clear up if the server connection is lost. | 1 | 922 | ## V8.3 Sensitive Private Data @@ -46,17 +46,17 @@ Compliance with this section implies compliance with V4 Access Control, and in p Note: Privacy regulations and laws, such as the Australian Privacy Principles APP-11 or GDPR, directly affect how applications must approach the implementation of storage, use, and transmission of sensitive personal information. This ranges from severe penalties to simple advice. Please consult your local laws and regulations, and consult a qualified privacy specialist or lawyer as required. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **8.3.1** | [MODIFIED, MERGED FROM 3.1.1, 13.1.3] Verify that sensitive data is only sent to the server in the HTTP message body or header fields and that the URL and query string do not contain sensitive information, such as an API key or session token. | ✓ | ✓ | ✓ | 598 | -| **8.3.2** | [DELETED, NOT IN SCOPE] | | | | | -| **8.3.3** | [DELETED, NOT IN SCOPE] | | | | | -| **8.3.4** | [DELETED, MERGED TO 1.8.1] | | | | | -| **8.3.5** | [MOVED TO 7.2.7] | | | | | -| **8.3.6** | [DELETED, NOT PRACTICAL] | | | | | -| **8.3.7** | [DELETED, COVERED BY 1.8.2] | | | | | -| **8.3.8** | [LEVEL L2 > L3] Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires. | | | ✓ | | -| **8.3.9** | [ADDED] Verify that sensitive information is removed from the metadata of user-submitted files unless storage is consented to by the user. | | ✓ | ✓ | 212 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **8.3.1** | [MODIFIED, MERGED FROM 3.1.1, 13.1.3] Verify that sensitive data is only sent to the server in the HTTP message body or header fields and that the URL and query string do not contain sensitive information, such as an API key or session token. | 1 | 598 | +| **8.3.2** | [DELETED, NOT IN SCOPE] | | | +| **8.3.3** | [DELETED, NOT IN SCOPE] | | | +| **8.3.4** | [DELETED, MERGED TO 1.8.1] | | | +| **8.3.5** | [MOVED TO 7.2.7] | | | +| **8.3.6** | [DELETED, NOT PRACTICAL] | | | +| **8.3.7** | [DELETED, COVERED BY 1.8.2] | | | +| **8.3.8** | [LEVEL L2 > L3] Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires. | 3 | | +| **8.3.9** | [ADDED] Verify that sensitive information is removed from the metadata of user-submitted files unless storage is consented to by the user. | 2 | 212 | When considering data protection, a primary consideration should be around bulk extraction or modification or excessive usage. For example, many social media systems only allow users to add 100 new friends per day, but which system these requests came from is not important. A banking platform might wish to block more than 5 transactions per hour transferring more than 1000 euro of funds to external institutions. Each system's requirements are likely to be very different, so deciding on "abnormal" must consider the threat model and business risk. Important criteria are the ability to detect, deter, or preferably block such abnormal bulk actions. diff --git a/5.0/en/0x17-V9-Communications.md b/5.0/en/0x17-V9-Communications.md index 5cd0d2fe4d..49d5564b96 100644 --- a/5.0/en/0x17-V9-Communications.md +++ b/5.0/en/0x17-V9-Communications.md @@ -23,56 +23,56 @@ In addition to outlining general principles and best practices, this document al ## V1.9 Communications Documentation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.9.1** | [DELETED, COVERED BY 9.1.1, 9.2.2, 9.3.1] | | | | | -| **1.9.2** | [DELETED, COVERED BY 9.3.2] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.9.1** | [DELETED, COVERED BY 9.1.1, 9.2.2, 9.3.1] | | | +| **1.9.2** | [DELETED, COVERED BY 9.3.2] | | | ## V9.1 HTTPS Communication with External Facing Services Ensure all HTTP traffic to external-facing services which the application exposes is sent encrypted, with publicly trusted certificates. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **9.1.1** | [MODIFIED, COVERS 1.9.1] Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications. | ✓ | ✓ | ✓ | 319 | -| **9.1.2** | [MOVED TO 9.4.1] | | | | | -| **9.1.3** | [MOVED TO 9.4.2] | | | | | -| **9.1.4** | [ADDED] Verify that external facing services use publicly trusted TLS certificates. | ✓ | ✓ | ✓ | 295 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **9.1.1** | [MODIFIED, COVERS 1.9.1] Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications. | 1 | 319 | +| **9.1.2** | [MOVED TO 9.4.1] | | | +| **9.1.3** | [MOVED TO 9.4.2] | | | +| **9.1.4** | [ADDED] Verify that external facing services use publicly trusted TLS certificates. | 1 | 295 | ## V9.2 General Service to Service Communication Security Server communications involve more than just HTTP. Connections to and from other systems must also be secure. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **9.2.1** | [MOVED TO 9.3.2] | | | | | -| **9.2.2** | [MODIFIED, COVERS 1.9.1] Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols. | | ✓ | ✓ | 319 | -| **9.2.3** | [DELETED, NOT IN SCOPE] | | | | | -| **9.2.4** | [MOVED TO 9.4.3] | | | | | -| **9.2.5** | [MOVED TO 7.2.6] | | | | | -| **9.2.6** | [ADDED] Verify that TLS clients validate certificates received before communicating with a TLS server. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **9.2.1** | [MOVED TO 9.3.2] | | | +| **9.2.2** | [MODIFIED, COVERS 1.9.1] Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols. | 2 | 319 | +| **9.2.3** | [DELETED, NOT IN SCOPE] | | | +| **9.2.4** | [MOVED TO 9.4.3] | | | +| **9.2.5** | [MOVED TO 7.2.6] | | | +| **9.2.6** | [ADDED] Verify that TLS clients validate certificates received before communicating with a TLS server. | 1 | | ## V9.3 HTTPS Communication between Internal Services HTTP traffic between internal-facing services should also be encrypted, ideally using TLS. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **9.3.1** | [ADDED, COVERS 1.9.1] Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications. | | ✓ | ✓ | 319 | -| **9.3.2** | [MODIFIED, MOVED FROM 9.2.1, COVERS 1.9.2] Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected. | | ✓ | ✓ | 295 | -| **9.3.3** | [MODIFIED, MOVED FROM 2.2.5] Verify that services communicating internally within a system (intra-service communications) use strong authentication to ensure that each endpoint is verified. Strong authentication methods, such as mTLS, should be employed to ensure identity, using public-key infrastructure and mechanisms that are resistant to replay attacks. For microservice architectures, consider using a service mesh to simplify certificate management and enhance security. | | | ✓ | 295 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **9.3.1** | [ADDED, COVERS 1.9.1] Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications. | 2 | 319 | +| **9.3.2** | [MODIFIED, MOVED FROM 9.2.1, COVERS 1.9.2] Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected. | 2 | 295 | +| **9.3.3** | [MODIFIED, MOVED FROM 2.2.5] Verify that services communicating internally within a system (intra-service communications) use strong authentication to ensure that each endpoint is verified. Strong authentication methods, such as mTLS, should be employed to ensure identity, using public-key infrastructure and mechanisms that are resistant to replay attacks. For microservice architectures, consider using a service mesh to simplify certificate management and enhance security. | 3 | 295 | ## V9.4 General TLS Security Guidance Use secure TLS configuration and up-to-date tools to review the configuration on a regular basis. While usage of wildcard TLS certificates is not inherently insecure, a compromise of a certificate that is deployed across all owned environments (e.g., production, staging, development, test, etc.) may lead to a compromise of the security posture of the applications using it. Proper protection, management, and usage of separate TLS certificates in different environments should be employed if possible. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **9.4.1** | [MODIFIED, MOVED FROM 9.1.2] Verify that only the latest recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy. | ✓ | ✓ | ✓ | 326 | -| **9.4.2** | [MOVED FROM 9.1.3] Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option. | ✓ | ✓ | ✓ | 326 | -| **9.4.3** | [MOVED FROM 9.2.4] Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | | ✓ | ✓ | 299 | -| **9.4.4** | [ADDED] Verify that Encrypted Client Hello (ECH) is supported and properly configured within the application’s TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes. | | | ✓ | | -| **9.4.5** | [ADDED] Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization. | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **9.4.1** | [MODIFIED, MOVED FROM 9.1.2] Verify that only the latest recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy. | 1 | 326 | +| **9.4.2** | [MOVED FROM 9.1.3] Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option. | 1 | 326 | +| **9.4.3** | [MOVED FROM 9.2.4] Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | 2 | 299 | +| **9.4.4** | [ADDED] Verify that Encrypted Client Hello (ECH) is supported and properly configured within the application’s TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes. | 3 | | +| **9.4.5** | [ADDED] Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization. | 3 | | ## References diff --git a/5.0/en/0x18-V10-Coding.md b/5.0/en/0x18-V10-Coding.md index 892294a12e..c407a27e82 100644 --- a/5.0/en/0x18-V10-Coding.md +++ b/5.0/en/0x18-V10-Coding.md @@ -10,13 +10,13 @@ This chapter also contains requirements to prevent the introduction of malicious ## V1.10 Secure Coding Documentation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.10.1** | [DELETED, NOT IN SCOPE] | | | | | -| **1.10.2** | [MODIFIED, MOVED FROM 14.2.5, MERGED FROM 14.2.4, COVERS 12.3.6] Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories. | | ✓ | ✓ | | -| **1.10.3** | [ADDED, SPLIT FROM 14.2.6] Verify that application documentation highlights "risky" third party libraries which should include: libraries which perform operations which are dangerous from a security perspective, libraries which are poorly maintained, unsupported, or end of life, libraries which have historically had several significant vulnerabilities, etc. | | | ✓ | 1061 | -| **1.10.4** | [ADDED, SPLIT FROM 1.14.5] Verify that application documentation highlights parts of the application where "risky" operations are being performed. "Risky" in this context means those with a high likelihood of being dangerously exploited such as: deserialization of untrusted data, raw file parsing, direct memory manipulation, etc. | | | ✓ | | -| **1.10.5** | [ADDED, SPLIT FROM 14.2.1, COVERS 1.14.3] Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.10.1** | [DELETED, NOT IN SCOPE] | | | +| **1.10.2** | [MODIFIED, MOVED FROM 14.2.5, MERGED FROM 14.2.4, COVERS 12.3.6] Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories. | 2 | | +| **1.10.3** | [ADDED, SPLIT FROM 14.2.6] Verify that application documentation highlights "risky" third party libraries which should include: libraries which perform operations which are dangerous from a security perspective, libraries which are poorly maintained, unsupported, or end of life, libraries which have historically had several significant vulnerabilities, etc. | 3 | 1061 | +| **1.10.4** | [ADDED, SPLIT FROM 1.14.5] Verify that application documentation highlights parts of the application where "risky" operations are being performed. "Risky" in this context means those with a high likelihood of being dangerously exploited such as: deserialization of untrusted data, raw file parsing, direct memory manipulation, etc. | 3 | | +| **1.10.5** | [ADDED, SPLIT FROM 14.2.1, COVERS 1.14.3] Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components. | 1 | | ## V10.1 Code Integrity @@ -26,20 +26,20 @@ The best defense against malicious code is "trust, but verify". Introducing unau Lead developers should regularly review code check-ins, particularly those that might access time, I/O, or network functions. --> -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **10.1.1** | [DELETED, NOT IN SCOPE] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **10.1.1** | [DELETED, NOT IN SCOPE] | | | ## V10.2 Malicious Code Search -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **10.2.1** | [DELETED, NOT PRACTICAL] | | | | | -| **10.2.2** | [DELETED, NOT PRACTICAL] | | | | | -| **10.2.3** | [DELETED, NOT PRACTICAL] | | | | | -| **10.2.4** | [DELETED, NOT PRACTICAL] | | | | | -| **10.2.5** | [DELETED, NOT PRACTICAL] | | | | | -| **10.2.6** | [DELETED, NOT PRACTICAL] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **10.2.1** | [DELETED, NOT PRACTICAL] | | | +| **10.2.2** | [DELETED, NOT PRACTICAL] | | | +| **10.2.3** | [DELETED, NOT PRACTICAL] | | | +| **10.2.4** | [DELETED, NOT PRACTICAL] | | | +| **10.2.5** | [DELETED, NOT PRACTICAL] | | | +| **10.2.6** | [DELETED, NOT PRACTICAL] | | | ## V10.3 Application Integrity @@ -47,52 +47,52 @@ Once an application is deployed, malicious code can still be inserted. Applicati Complying with this section is likely to be operational and continuous. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **10.3.1** | [MODIFIED, LEVEL L1 > L3] Verify that, if the application has an auto-update feature, updates should be digitally signed, with the digital signature being validated before installing or executing the update. | | | ✓ | 16 | -| **10.3.2** | [MOVED TO 10.6.2] | | | | | -| **10.3.3** | [DELETED, NOT IN SCOPE] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **10.3.1** | [MODIFIED, LEVEL L1 > L3] Verify that, if the application has an auto-update feature, updates should be digitally signed, with the digital signature being validated before installing or executing the update. | 3 | 16 | +| **10.3.2** | [MOVED TO 10.6.2] | | | +| **10.3.3** | [DELETED, NOT IN SCOPE] | | | ## V10.4 Defensive Coding -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **10.4.1** | [ADDED] Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations to avoid type juggling or type confusion vulnerabilities caused by the application code making an assumption about a variable type. | ✓ | ✓ | ✓ | 843 | -| **10.4.2** | [ADDED] Verify that the application avoids DOM clobbering when using client-side JavaScript by employing explicit variable declarations, performing strict type checking, avoiding storing global variables on the document object, and implementing namespace isolation. | | ✓ | ✓ | 79 | -| **10.4.3** | [ADDED] Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals. | | ✓ | ✓ | | -| **10.4.4** | [MODIFIED, MOVED FROM 5.1.2] Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action. | ✓ | ✓ | ✓ | 915 | -| **10.4.5** | [ADDED] Verify that the application only returns data which the user has permission to access. For example, the API response does not return a full object with attributes that contain values the user has no permission to access, despite having permission to access the data object itself. | ✓ | ✓ | ✓ | | -| **10.4.6** | [ADDED] Verify that the application is able to discern and utilizes the user's true IP address to provide for sensitive functions, including rate limiting and logging. | | ✓ | ✓ | 348 | -| **10.4.7** | [MODIFIED, MOVED FROM 5.1.1, LEVEL L1 > L2] Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or header fields). | | ✓ | ✓ | 235 | -| **10.4.8** | [ADDED] Verify that where the application back-end makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **10.4.1** | [ADDED] Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations to avoid type juggling or type confusion vulnerabilities caused by the application code making an assumption about a variable type. | 1 | 843 | +| **10.4.2** | [ADDED] Verify that the application avoids DOM clobbering when using client-side JavaScript by employing explicit variable declarations, performing strict type checking, avoiding storing global variables on the document object, and implementing namespace isolation. | 2 | 79 | +| **10.4.3** | [ADDED] Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals. | 2 | | +| **10.4.4** | [MODIFIED, MOVED FROM 5.1.2] Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action. | 1 | 915 | +| **10.4.5** | [ADDED] Verify that the application only returns data which the user has permission to access. For example, the API response does not return a full object with attributes that contain values the user has no permission to access, despite having permission to access the data object itself. | 1 | | +| **10.4.6** | [ADDED] Verify that the application is able to discern and utilizes the user's true IP address to provide for sensitive functions, including rate limiting and logging. | 2 | 348 | +| **10.4.7** | [MODIFIED, MOVED FROM 5.1.1, LEVEL L1 > L2] Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or header fields). | 2 | 235 | +| **10.4.8** | [ADDED] Verify that where the application back-end makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality. | 2 | | ## V10.5 Security Architecture -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **10.5.1** | [ADDED, SPLIT FROM 1.14.5, 14.2.6] Verify that the application implements additional protections around parts of the application which are documented as performing "risky" operations or using "risky" third-party libraries. This could include techniques such as sandboxing, encapsulation, containerization or network level isolation to delay and deter attackers who compromise one part of an application from pivoting elsewhere in the application. | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **10.5.1** | [ADDED, SPLIT FROM 1.14.5, 14.2.6] Verify that the application implements additional protections around parts of the application which are documented as performing "risky" operations or using "risky" third-party libraries. This could include techniques such as sandboxing, encapsulation, containerization or network level isolation to delay and deter attackers who compromise one part of an application from pivoting elsewhere in the application. | 3 | | ## V10.6 Code Dependencies Dependency management is critical to the safe operation of any application of any type. Failure to keep up to date with outdated or insecure dependencies is the root cause of the largest and most expensive attacks to date. While being up-to-date with patches is essential, relying solely on updates for publicly disclosed vulnerabilities introduces risk, as vendors may fix security issues without public announcements. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **10.6.1** | [ADDED, SPLIT FROM 14.2.1, COVERS 1.14.3] Verify that the application only contains components which have not breached the documented update and remediation time frames. | ✓ | ✓ | ✓ | | -| **10.6.2** | [MODIFIED, MOVED FROM 10.3.2] Verify that third-party components and all of their transitive dependencies are included from the expected repository, whether internally owned or an external source, and that there is no risk of a dependency confusion attack. | ✓ | ✓ | ✓ | 427 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **10.6.1** | [ADDED, SPLIT FROM 14.2.1, COVERS 1.14.3] Verify that the application only contains components which have not breached the documented update and remediation time frames. | 1 | | +| **10.6.2** | [MODIFIED, MOVED FROM 10.3.2] Verify that third-party components and all of their transitive dependencies are included from the expected repository, whether internally owned or an external source, and that there is no risk of a dependency confusion attack. | 1 | 427 | ## V10.7 Concurrency Without proper synchronization, concurrent access to shared resources can result in corrupted data, system crashes, or unreliable application behavior. Furthermore, race conditions can often be chained to perform privilege escalations or remote code execution. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **10.7.1** | [MODIFIED, MOVED FROM 1.11.3] Verify that only thread-safe types are used in multi-threaded contexts, or that non-thread-safe types are properly synchronized to prevent race conditions. | | | ✓ | 362 | -| **10.7.2** | [MODIFIED, MOVED FROM 1.11.2, LEVEL L2 > L3] Verify that concurrent access to shared resources is controlled using synchronization primitives (e.g., locks, mutexes, semaphores) to prevent race conditions and ensure atomic operations on these resources. | | | ✓ | 366 | -| **10.7.3** | [MODIFIED, MOVED FROM 11.1.6] Verify that all access to shared resources is consistently checked and accessed in a single atomic operation to prevent Time-of-Check to Time-of-Use (TOC/TOU) race conditions, ensuring resource state consistency between check and use. | | ✓ | ✓ | 367 | -| **10.7.4** | [ADDED] Verify that resource acquisition uses a consistent locking strategy to avoid circular dependencies and ensure forward progress, preventing both deadlocks and livelock scenarios. | | | ✓ | 833 | -| **10.7.5** | [ADDED] Verify that resource allocation policies prevent thread starvation by ensuring fair access to resources, such as by leveraging thread pools, allowing lower-priority threads to proceed within a reasonable timeframe. | | | ✓ | 410 | -| **10.7.6** | [ADDED] Verify that locking primitives are only accessible to the owning class or module and are not publicly modifiable, ensuring that locks cannot be inadvertently or maliciously modified by external classes or code. | | | ✓ | 412 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **10.7.1** | [MODIFIED, MOVED FROM 1.11.3] Verify that only thread-safe types are used in multi-threaded contexts, or that non-thread-safe types are properly synchronized to prevent race conditions. | 3 | 362 | +| **10.7.2** | [MODIFIED, MOVED FROM 1.11.2, LEVEL L2 > L3] Verify that concurrent access to shared resources is controlled using synchronization primitives (e.g., locks, mutexes, semaphores) to prevent race conditions and ensure atomic operations on these resources. | 3 | 366 | +| **10.7.3** | [MODIFIED, MOVED FROM 11.1.6] Verify that all access to shared resources is consistently checked and accessed in a single atomic operation to prevent Time-of-Check to Time-of-Use (TOC/TOU) race conditions, ensuring resource state consistency between check and use. | 2 | 367 | +| **10.7.4** | [ADDED] Verify that resource acquisition uses a consistent locking strategy to avoid circular dependencies and ensure forward progress, preventing both deadlocks and livelock scenarios. | 3 | 833 | +| **10.7.5** | [ADDED] Verify that resource allocation policies prevent thread starvation by ensuring fair access to resources, such as by leveraging thread pools, allowing lower-priority threads to proceed within a reasonable timeframe. | 3 | 410 | +| **10.7.6** | [ADDED] Verify that locking primitives are only accessible to the owning class or module and are not publicly modifiable, ensuring that locks cannot be inadvertently or maliciously modified by external classes or code. | 3 | 412 | ## References diff --git a/5.0/en/0x19-V11-BusLogic.md b/5.0/en/0x19-V11-BusLogic.md index 1d664c221e..91b9900e29 100644 --- a/5.0/en/0x19-V11-BusLogic.md +++ b/5.0/en/0x19-V11-BusLogic.md @@ -10,47 +10,47 @@ Ensure that a verified application satisfies the following high-level requiremen ## V1.11 Business Logic Documentation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.11.1** | [DELETED, NOT IN SCOPE] | | | | | -| **1.11.2** | [MOVED TO 10.7.2] | | | | | -| **1.11.3** | [MOVED TO 10.7.1] | | | | | -| **1.11.4** | [ADDED] Verify that expectations for business logic limits and validations are clearly documented including both per-user and also globally across the application. | | ✓ | ✓ | | -| **1.11.5** | [ADDED, SPLIT FROM 1.5.1, LEVEL L2 > L1] Verify that input validation rules define how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, e-mail addresses, telephone numbers, or it could be an internal data format. | ✓ | ✓ | ✓ | 20 | -| **1.11.6** | [ADDED, SPLIT FROM 1.5.1, LEVEL L2 > L1] Verify that input validation rules are documented and define how to ensure the logical and contextual consistency of combined data items, such as checking that suburb and zip code match. | ✓ | ✓ | ✓ | 20 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.11.1** | [DELETED, NOT IN SCOPE] | | | +| **1.11.2** | [MOVED TO 10.7.2] | | | +| **1.11.3** | [MOVED TO 10.7.1] | | | +| **1.11.4** | [ADDED] Verify that expectations for business logic limits and validations are clearly documented including both per-user and also globally across the application. | 2 | | +| **1.11.5** | [ADDED, SPLIT FROM 1.5.1, LEVEL L2 > L1] Verify that input validation rules define how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, e-mail addresses, telephone numbers, or it could be an internal data format. | 1 | 20 | +| **1.11.6** | [ADDED, SPLIT FROM 1.5.1, LEVEL L2 > L1] Verify that input validation rules are documented and define how to ensure the logical and contextual consistency of combined data items, such as checking that suburb and zip code match. | 1 | 20 | ## 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 into the system to protect against likely external threats - it cannot be added using web application firewalls or secure communications. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **11.1.1** | Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps. | ✓ | ✓ | ✓ | 841 | -| **11.1.2** | [MOVED TO 11.2.1] | | | | | -| **11.1.3** | [MODIFIED, MERGED FROM 11.1.5] Verify that business logic limits and validations are implemented as per the application's documentation, to avoid business logic flaws being exploited such as buying items for a negative amount. | ✓ | ✓ | ✓ | | -| **11.1.4** | [MOVED TO 11.2.2] | | | | | -| **11.1.5** | [DELETED, MERGED TO 11.1.3] | | | | | -| **11.1.6** | [MOVED TO 10.7.3] | | | | | -| **11.1.7** | [MOVED TO 7.2.4] | | | | | -| **11.1.8** | [MOVED TO 7.2.5] | | | | | -| **11.1.9** | [ADDED] Verify that "atomic transactions" are being used at the business logic level such that either a business logic operation succeeds in its entirety, or it is rolled back to the previous correct state. | | ✓ | ✓ | | -| **11.1.10** | [ADDED] Verify that very high-value business logic flows are restricted with multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to critical nuclear facility operations, healthcare record modifications, access to classified information, or safety overrides in manufacturing. | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **11.1.1** | Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps. | 1 | 841 | +| **11.1.2** | [MOVED TO 11.2.1] | | | +| **11.1.3** | [MODIFIED, MERGED FROM 11.1.5] Verify that business logic limits and validations are implemented as per the application's documentation, to avoid business logic flaws being exploited such as buying items for a negative amount. | 1 | | +| **11.1.4** | [MOVED TO 11.2.2] | | | +| **11.1.5** | [DELETED, MERGED TO 11.1.3] | | | +| **11.1.6** | [MOVED TO 10.7.3] | | | +| **11.1.7** | [MOVED TO 7.2.4] | | | +| **11.1.8** | [MOVED TO 7.2.5] | | | +| **11.1.9** | [ADDED] Verify that "atomic transactions" are being used at the business logic level such that either a business logic operation succeeds in its entirety, or it is rolled back to the previous correct state. | 2 | | +| **11.1.10** | [ADDED] Verify that very high-value business logic flows are restricted with multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to critical nuclear facility operations, healthcare record modifications, access to classified information, or safety overrides in manufacturing. | 3 | | ## V11.2 Anti-automation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **11.2.1** | [MODIFIED, MOVED FROM 11.1.2, LEVEL L1 > L3] Verify that business logic processes require realistic human timing, preventing excessively rapid transaction submissions. | | | ✓ | 799 | -| **11.2.2** | [MODIFIED, MOVED FROM 11.1.4, LEVEL L1 > L2] Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage data creation, quota exhaustion, rate limit breaches, denial of service, or overuse of costly resources. | | ✓ | ✓ | 770 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **11.2.1** | [MODIFIED, MOVED FROM 11.1.2, LEVEL L1 > L3] Verify that business logic processes require realistic human timing, preventing excessively rapid transaction submissions. | 3 | 799 | +| **11.2.2** | [MODIFIED, MOVED FROM 11.1.4, LEVEL L1 > L2] Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage data creation, quota exhaustion, rate limit breaches, denial of service, or overuse of costly resources. | 2 | 770 | ## V11.3 Input Validation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **11.3.1** | [MODIFIED, MOVED FROM 5.1.3] Verify that input which is used to make business or security decisions is validated using positive validation, against an allowed list of values, patterns or ranges to enforce business or functional expectations for that input. For L2, input validation should be implemented globally. | ✓ | ✓ | ✓ | 20 | -| **11.3.2** | [ADDED, SPLIT FROM 5.1.4] Verify that data items with an expected structure, and which are used to make business or security decisions, are validated according to the pre-defined rules. For L2, input validation must be implemented globally. | ✓ | ✓ | ✓ | 20 | -| **11.3.3** | [ADDED, SPLIT FROM 5.1.4, LEVEL L1 > L2] Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | | ✓ | ✓ | 20 | -| **11.3.4** | [MODIFIED, MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability, it must not be relied upon as a security control. | ✓ | ✓ | ✓ | 602 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **11.3.1** | [MODIFIED, MOVED FROM 5.1.3] Verify that input which is used to make business or security decisions is validated using positive validation, against an allowed list of values, patterns or ranges to enforce business or functional expectations for that input. For L2, input validation should be implemented globally. | 1 | 20 | +| **11.3.2** | [ADDED, SPLIT FROM 5.1.4] Verify that data items with an expected structure, and which are used to make business or security decisions, are validated according to the pre-defined rules. For L2, input validation must be implemented globally. | 1 | 20 | +| **11.3.3** | [ADDED, SPLIT FROM 5.1.4, LEVEL L1 > L2] Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | 2 | 20 | +| **11.3.4** | [MODIFIED, MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability, it must not be relied upon as a security control. | 1 | 602 | ## References diff --git a/5.0/en/0x20-V12-Files-Resources.md b/5.0/en/0x20-V12-Files-Resources.md index 58c28e11c0..317c830c43 100644 --- a/5.0/en/0x20-V12-Files-Resources.md +++ b/5.0/en/0x20-V12-Files-Resources.md @@ -6,79 +6,79 @@ Ensure that untrusted files and other resources are handled safely to prevent de ## V1.12 Secure File Upload Documentation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.12.1** | [DELETED] | | | | | -| **1.12.2** | [DELETED, MERGED TO 50.6.1] | | | | | -| **1.12.3** | [ADDED] Verify that, if the application allows uploading files, the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.12.1** | [DELETED] | | | +| **1.12.2** | [DELETED, MERGED TO 50.6.1] | | | +| **1.12.3** | [ADDED] Verify that, if the application allows uploading files, the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process. | 1 | | ## V12.1 File Upload Upload functionality is a key source of untrusted files. These should be carefully validated to prevent risks such as denial of service, unauthorized access, and resource exhaustion. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **12.1.1** | [MODIFIED] Verify that the application will only accept files of a size which it can process without causing a loss of performance or denial of service attack. | ✓ | ✓ | ✓ | 400 | -| **12.1.2** | [GRAMMAR] Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | | ✓ | ✓ | 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 | -| **12.1.4** | [ADDED] Verify that the application does not allow uploading compressed files containing symlinks unless this is specifically required (in which case it will be necessary to enforce an allowlist of the files that can be symlinked to). | | ✓ | ✓ | 61 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **12.1.1** | [MODIFIED] Verify that the application will only accept files of a size which it can process without causing a loss of performance or denial of service attack. | 1 | 400 | +| **12.1.2** | [GRAMMAR] Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | 2 | 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. | 2 | 770 | +| **12.1.4** | [ADDED] Verify that the application does not allow uploading compressed files containing symlinks unless this is specifically required (in which case it will be necessary to enforce an allowlist of the files that can be symlinked to). | 2 | 61 | ## V12.2 File Integrity and Content Uploaded files and uploaded files within archives must match expected file types and content formats, and oversized images must be blocked to prevent pixel flood attacks. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **12.2.1** | [MODIFIED] Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. | | ✓ | ✓ | 434 | -| **12.2.2** | [ADDED] Verify that the application blocks uploaded images with a pixel size larger than the maximum allowed, to prevent pixel flood attacks. | ✓ | ✓ | ✓ | 400 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **12.2.1** | [MODIFIED] Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. | 2 | 434 | +| **12.2.2** | [ADDED] Verify that the application blocks uploaded images with a pixel size larger than the maximum allowed, to prevent pixel flood attacks. | 1 | 400 | ## V12.3 File Execution File operations should not rely on user-submitted filenames or metadata to avoid path traversal and inclusion attacks, and server-side file processing should ignore user-provided path details to prevent vulnerabilities like zip slip. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **12.3.1** | [MODIFIED, MERGED FROM 12.3.2, 12.3.3, 5.3.9] Verify that file operations avoid using user-submitted filenames or file metadata when creating file paths to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks. Instead, use internal, trusted data for file I/O. If user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. | ✓ | ✓ | ✓ | 73 | -| **12.3.2** | [DELETED, MERGED TO 12.3.1] | | | | | -| **12.3.3** | [DELETED, MERGED TO 12.3.1] | | | | | -| **12.3.4** | [MOVED TO 12.5.3] | | | | | -| **12.3.5** | [DELETED, COVERED BY 5.3.8] | | | | | -| **12.3.6** | [DELETED, COVERED BY 1.10.2] | | | | | -| **12.3.7** | [ADDED] Verify that server-side file processing such as file decompression ignores user-provided path information to prevent vulnerabilities such as zip slip. | ✓ | ✓ | ✓ | 23 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **12.3.1** | [MODIFIED, MERGED FROM 12.3.2, 12.3.3, 5.3.9] Verify that file operations avoid using user-submitted filenames or file metadata when creating file paths to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks. Instead, use internal, trusted data for file I/O. If user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. | 1 | 73 | +| **12.3.2** | [DELETED, MERGED TO 12.3.1] | | | +| **12.3.3** | [DELETED, MERGED TO 12.3.1] | | | +| **12.3.4** | [MOVED TO 12.5.3] | | | +| **12.3.5** | [DELETED, COVERED BY 5.3.8] | | | +| **12.3.6** | [DELETED, COVERED BY 1.10.2] | | | +| **12.3.7** | [ADDED] Verify that server-side file processing such as file decompression ignores user-provided path information to prevent vulnerabilities such as zip slip. | 1 | 23 | ## V12.4 File Storage Files from untrusted sources, when stored in public folders, must not be executable as server-side code. Files from untrusted sources must also be scanned by antivirus software to prevent serving malicious content. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **12.4.1** | [MODIFIED] Verify that files uploaded or generated by untrusted input which are stored in a public folder are not executable as server-side program code when accessed directly by an end user. | ✓ | ✓ | ✓ | 552 | -| **12.4.2** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. | ✓ | ✓ | ✓ | 509 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **12.4.1** | [MODIFIED] Verify that files uploaded or generated by untrusted input which are stored in a public folder are not executable as server-side program code when accessed directly by an end user. | 1 | 552 | +| **12.4.2** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. | 1 | 509 | ## V12.5 File Download User-submitted filenames should be validated or ignored in the Content-Disposition header for downloads, and that served filenames are encoded or sanitized to prevent injection attacks. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **12.5.1** | [MOVED TO 14.3.6] | | | | | -| **12.5.2** | [MOVED TO 50.6.1] | | | | | -| **12.5.3** | [MODIFIED, MOVED FROM 12.3.4] Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response. | ✓ | ✓ | ✓ | 641 | -| **12.5.4** | [ADDED] Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **12.5.1** | [MOVED TO 14.3.6] | | | +| **12.5.2** | [MOVED TO 50.6.1] | | | +| **12.5.3** | [MODIFIED, MOVED FROM 12.3.4] Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response. | 1 | 641 | +| **12.5.4** | [ADDED] Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | 1 | | ## V12.6 SSRF Protection -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **12.6.1** | [MOVED TO 14.6.1] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **12.6.1** | [MOVED TO 14.6.1] | | | ## V12.7 Application Resources Applications must release system resources like database connections, open files, and threads after use to prevent resource exhaustion. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **12.7.1** | [ADDED] Verify that the application proactively releases system resources, such as database connections, open files, threads, etc, when it finishes using them to prevent resource exhaustion. | | ✓ | ✓ | 404 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **12.7.1** | [ADDED] Verify that the application proactively releases system resources, such as database connections, open files, threads, etc, when it finishes using them to prevent resource exhaustion. | 2 | 404 | ## References diff --git a/5.0/en/0x21-V13-API.md b/5.0/en/0x21-V13-API.md index c50cea8230..9283f0d843 100644 --- a/5.0/en/0x21-V13-API.md +++ b/5.0/en/0x21-V13-API.md @@ -12,16 +12,16 @@ This is a placeholder for future documentation requirements. ## V13.1 Generic Web Service Security -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **13.1.1** | [MOVED TO 5.5.5] | | | | | -| **13.1.2** | [DELETED] | | | | | -| **13.1.3** | [DELETED, MERGED TO 8.3.1] | | | | | -| **13.1.4** | [DELETED, COVERED BY 4.1.6] | | | | | -| **13.1.5** | [DELETED, INSUFFICIENT IMPACT] | | | | | -| **13.1.6** | [MODIFIED, MOVED FROM 13.2.6, COVERS 13.3.2, LEVEL L2 > L3] Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems. | | | ✓ | 345 | -| **13.1.7** | [MODIFIED, MOVED FROM 14.4.1, COVERS 5.3.2] Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml". | ✓ | ✓ | ✓ | 173 | -| **13.1.8** | [ADDED] Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints do not implement transparent redirects. This is to avoid a situation where a client is erroneously sending unencrypted HTTP requests but, since the requests are being automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **13.1.1** | [MOVED TO 5.5.5] | | | +| **13.1.2** | [DELETED] | | | +| **13.1.3** | [DELETED, MERGED TO 8.3.1] | | | +| **13.1.4** | [DELETED, COVERED BY 4.1.6] | | | +| **13.1.5** | [DELETED, INSUFFICIENT IMPACT] | | | +| **13.1.6** | [MODIFIED, MOVED FROM 13.2.6, COVERS 13.3.2, LEVEL L2 > L3] Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems. | 3 | 345 | +| **13.1.7** | [MODIFIED, MOVED FROM 14.4.1, COVERS 5.3.2] Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml". | 1 | 173 | +| **13.1.8** | [ADDED] Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints do not implement transparent redirects. This is to avoid a situation where a client is erroneously sending unencrypted HTTP requests but, since the requests are being automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered. | 2 | | ## V13.2 Web Services @@ -31,56 +31,56 @@ Due to the lack of a formal stable version of the JSON schema validation specifi 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 chapter V5. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **13.2.1** | [MOVED TO 50.4.4] | | | | | -| **13.2.2** | [MODIFIED, MERGED FROM 13.3.1, LEVEL L1 > L3] Verify that structured data objects are validated to ensure they are properly formed, followed by validation of each input field before any processing of that data takes place. This could involve implementing schema validation for formats like JSON and XML. | | | ✓ | 20 | -| **13.2.3** | [DELETED, COVERED BY 50.4.1, 50.4.3] | | | | | -| **13.2.4** | [DELETED] | | | | | -| **13.2.5** | [MOVED TO 50.4.3] | | | | | -| **13.2.6** | [MOVED TO 13.1.6] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **13.2.1** | [MOVED TO 50.4.4] | | | +| **13.2.2** | [MODIFIED, MERGED FROM 13.3.1, LEVEL L1 > L3] Verify that structured data objects are validated to ensure they are properly formed, followed by validation of each input field before any processing of that data takes place. This could involve implementing schema validation for formats like JSON and XML. | 3 | 20 | +| **13.2.3** | [DELETED, COVERED BY 50.4.1, 50.4.3] | | | +| **13.2.4** | [DELETED] | | | +| **13.2.5** | [MOVED TO 50.4.3] | | | +| **13.2.6** | [MOVED TO 13.1.6] | | | ## V13.3 SOAP Web Service -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **13.3.1** | [DELETED, MERGED TO 13.2.2] | | | | | -| **13.3.2** | [DELETED, COVERED BY 13.1.6] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **13.3.1** | [DELETED, MERGED TO 13.2.2] | | | +| **13.3.2** | [DELETED, COVERED BY 13.1.6] | | | ## V13.4 GraphQL GraphQL is becoming more common as a way of creating data rich clients which are not coupled to a varierty of different backend services. However, this mechanism also comes with some specific security considerations. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **13.4.1** | [GRAMMAR] Verify that a query allowlist or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used. | | ✓ | ✓ | 770 | -| **13.4.2** | [MODIFIED] Verify that authorization logic is implemented at the business logic layer instead of the GraphQL or resolver layer. | | ✓ | ✓ | 285 | -| **13.4.3** | [ADDED] Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **13.4.1** | [GRAMMAR] Verify that a query allowlist or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used. | 2 | 770 | +| **13.4.2** | [MODIFIED] Verify that authorization logic is implemented at the business logic layer instead of the GraphQL or resolver layer. | 2 | 285 | +| **13.4.3** | [ADDED] Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties. | 2 | | ## V13.5 WebSocket -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **13.5.1** | [ADDED] Verify that WebSocket over TLS (WSS) is used for all WebSocket connections. | ✓ | ✓ | ✓ | 319 | -| **13.5.2** | [ADDED] Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application. | ✓ | ✓ | ✓ | 346 | -| **13.5.3** | [ADDED] Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this which comply with the relevant Session Management security requirements. | ✓ | ✓ | ✓ | 331 | -| **13.5.4** | [ADDED] Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel. | ✓ | ✓ | ✓ | 319 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **13.5.1** | [ADDED] Verify that WebSocket over TLS (WSS) is used for all WebSocket connections. | 1 | 319 | +| **13.5.2** | [ADDED] Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application. | 1 | 346 | +| **13.5.3** | [ADDED] Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this which comply with the relevant Session Management security requirements. | 1 | 331 | +| **13.5.4** | [ADDED] Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel. | 1 | 319 | ## V13.6 HTTP Request Header Validation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **13.6.1** | [MODIFIED, MOVED FROM 14.5.1] Verify that the application only responds to HTTP methods in use by the application or by the API (including OPTIONS during preflight requests) and unused methods (e.g., TRACE) are blocked. | ✓ | ✓ | ✓ | 749 | -| **13.6.2** | [ADDED] Verify that all application components, including load balancers, firewalls, and application servers, comply with RFC 2616 by ignoring the Content-Length header field when a Transfer-Encoding header field is present, to prevent HTTP Request Smuggling. | | ✓ | ✓ | 444 | -| **13.6.3** | [ADDED] Verify that any HTTP header field used by the application and defined by intermediary devices like load balancers or proxies, such as X-Real-IP and X-Forwarded-*, cannot be overridden by the end-user. | | ✓ | ✓ | 346 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **13.6.1** | [MODIFIED, MOVED FROM 14.5.1] Verify that the application only responds to HTTP methods in use by the application or by the API (including OPTIONS during preflight requests) and unused methods (e.g., TRACE) are blocked. | 1 | 749 | +| **13.6.2** | [ADDED] Verify that all application components, including load balancers, firewalls, and application servers, comply with RFC 2616 by ignoring the Content-Length header field when a Transfer-Encoding header field is present, to prevent HTTP Request Smuggling. | 2 | 444 | +| **13.6.3** | [ADDED] Verify that any HTTP header field used by the application and defined by intermediary devices like load balancers or proxies, such as X-Real-IP and X-Forwarded-*, cannot be overridden by the end-user. | 2 | 346 | ## V13.7 HTTP/2 -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **13.7.1** | [ADDED] Verify that the value in the Content-Length request header field matches the calculated length using the built-in mechanism. | ✓ | ✓ | ✓ | 400 | -| **13.7.2** | [ADDED] Verify that all Transfer-Encoding header fields are stripped from the message or that the request is blocked entirely. | ✓ | ✓ | ✓ | | -| **13.7.3** | [ADDED] Verify that a full CRLF (\r\n) sequence is neutralized inside a HTTP/2 header. | ✓ | ✓ | ✓ | 113 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **13.7.1** | [ADDED] Verify that the value in the Content-Length request header field matches the calculated length using the built-in mechanism. | 1 | 400 | +| **13.7.2** | [ADDED] Verify that all Transfer-Encoding header fields are stripped from the message or that the request is blocked entirely. | 1 | | +| **13.7.3** | [ADDED] Verify that a full CRLF (\r\n) sequence is neutralized inside a HTTP/2 header. | 1 | 113 | ## References diff --git a/5.0/en/0x22-V14-Config.md b/5.0/en/0x22-V14-Config.md index d22a3d4db1..fb6f472be2 100644 --- a/5.0/en/0x22-V14-Config.md +++ b/5.0/en/0x22-V14-Config.md @@ -11,15 +11,15 @@ Configuration of the application out of the box should be safe to be on the Inte ## V1.14 Configuration Documentation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.14.1** | [DELETED, NOT IN SCOPE] | | | | | -| **1.14.2** | [DELETED, NOT IN SCOPE] | | | | | -| **1.14.3** | [DELETED, COVERED BY 1.10.5, 10.6.1] | | | | | -| **1.14.4** | [DELETED, NOT IN SCOPE] | | | | | -| **1.14.5** | [SPLIT TO 1.10.4, 10.5.1] | | | | | -| **1.14.6** | [MOVED TO 50.8.2] | | | | | -| **1.14.7** | [MODIFIED, MOVED FROM 1.1.5] Verify that all communication needs for the application are documented. This should include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect. | | ✓ | ✓ | 1059 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.14.1** | [DELETED, NOT IN SCOPE] | | | +| **1.14.2** | [DELETED, NOT IN SCOPE] | | | +| **1.14.3** | [DELETED, COVERED BY 1.10.5, 10.6.1] | | | +| **1.14.4** | [DELETED, NOT IN SCOPE] | | | +| **1.14.5** | [SPLIT TO 1.10.4, 10.5.1] | | | +| **1.14.6** | [MOVED TO 50.8.2] | | | +| **1.14.7** | [MODIFIED, MOVED FROM 1.1.5] Verify that all communication needs for the application are documented. This should include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect. | 2 | 1059 | ## V14.1 Build and Deploy @@ -31,29 +31,29 @@ If traditional models are still in place, then manual steps must be taken to har Compliance with this section requires an automated build system, and access to build and deployment scripts. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.1.1** | [DELETED, NOT IN SCOPE] | | | | | -| **14.1.2** | [LEVEL L2 > L3] Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found. | | | ✓ | 120 | -| **14.1.3** | [MODIFIED] Verify that configuration hardening is performed on all third-party products, libraries, frameworks and services as per their individual recommendations. | | ✓ | ✓ | 16 | -| **14.1.4** | [DELETED, NOT IN SCOPE] | | | | | -| **14.1.5** | [MODIFIED] Verify that deployed environments are short lived and frequently redeployed to a "known good" but updated state. Alternatively, long lived environments should use some form of "drift prevention" to ensure that deployed configurations are not changed to an insecure state. | | | ✓ | | -| **14.1.6** | [MOVED FROM 14.2.2] Verify that all unneeded features, documentation, sample applications and configurations are removed. | ✓ | ✓ | ✓ | 1002 | -| **14.1.7** | [ADDED] Verify that production environment does not include test code. | | ✓ | ✓ | 489 | -| **14.1.8** | [ADDED] Verify that data, state information, and server instances related to the build and deployment process do not persist after the process has ended. (Ephemerality). | | | ✓ | | -| **14.1.9** | [ADDED] Verify that application code or functionality can only be changed via the standard update or build process and not directly in production through application functionality or some other direct modification mechanism. | | ✓ | ✓ | | -| **14.1.10** | [MODIFIED, MOVED FROM 2.5.4] Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled. | ✓ | ✓ | ✓ | 798 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.1.1** | [DELETED, NOT IN SCOPE] | | | +| **14.1.2** | [LEVEL L2 > L3] Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found. | 3 | 120 | +| **14.1.3** | [MODIFIED] Verify that configuration hardening is performed on all third-party products, libraries, frameworks and services as per their individual recommendations. | 2 | 16 | +| **14.1.4** | [DELETED, NOT IN SCOPE] | | | +| **14.1.5** | [MODIFIED] Verify that deployed environments are short lived and frequently redeployed to a "known good" but updated state. Alternatively, long lived environments should use some form of "drift prevention" to ensure that deployed configurations are not changed to an insecure state. | 3 | | +| **14.1.6** | [MOVED FROM 14.2.2] Verify that all unneeded features, documentation, sample applications and configurations are removed. | 1 | 1002 | +| **14.1.7** | [ADDED] Verify that production environment does not include test code. | 2 | 489 | +| **14.1.8** | [ADDED] Verify that data, state information, and server instances related to the build and deployment process do not persist after the process has ended. (Ephemerality). | 3 | | +| **14.1.9** | [ADDED] Verify that application code or functionality can only be changed via the standard update or build process and not directly in production through application functionality or some other direct modification mechanism. | 2 | | +| **14.1.10** | [MODIFIED, MOVED FROM 2.5.4] Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled. | 1 | 798 | ## V14.2 Dependency -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.2.1** | [SPLIT TO 1.10.5, 10.6.1] | | | | | -| **14.2.2** | [MOVED TO 14.1.6] | | | | | -| **14.2.3** | [MOVED TO 50.7.1] | | | | | -| **14.2.4** | [DELETED, MERGED TO 1.10.2] | | | | | -| **14.2.5** | [MOVED TO 1.10.2] | | | | | -| **14.2.6** | [SPLIT TO 1.10.3, 10.5.1] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.2.1** | [SPLIT TO 1.10.5, 10.6.1] | | | +| **14.2.2** | [MOVED TO 14.1.6] | | | +| **14.2.3** | [MOVED TO 50.7.1] | | | +| **14.2.4** | [DELETED, MERGED TO 1.10.2] | | | +| **14.2.5** | [MOVED TO 1.10.2] | | | +| **14.2.6** | [SPLIT TO 1.10.3, 10.5.1] | | | ## V14.3 Unintended Information Leakage @@ -61,63 +61,63 @@ Configurations for production should be hardened to protect against common attac For example, hiding the version of server-side components does not fix the need to patch all components, and disabling the folder listing does not eliminate the need to use authorization controls or keep files away from the public folder, but it raises the bar. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.3.1** | [DELETED] | | | | | -| **14.3.2** | [MODIFIED] Verify that debug modes are disabled in production environments for every component to prevent exposure of debug features and unintended information leakage. | ✓ | ✓ | ✓ | 497 | -| **14.3.3** | [MODIFIED] Verify that the application does not expose detailed version information of server-side components. | ✓ | ✓ | ✓ | 200 | -| **14.3.4** | [ADDED, SPLIT FROM 4.3.2] Verify that directory browsing is disabled unless deliberately desired. | ✓ | ✓ | ✓ | 548 | -| **14.3.5** | [ADDED, SPLIT FROM 4.3.2] Verify that the application does not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders. | ✓ | ✓ | ✓ | | -| **14.3.6** | [GRAMMAR, MOVED FROM 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 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.3.1** | [DELETED] | | | +| **14.3.2** | [MODIFIED] Verify that debug modes are disabled in production environments for every component to prevent exposure of debug features and unintended information leakage. | 1 | 497 | +| **14.3.3** | [MODIFIED] Verify that the application does not expose detailed version information of server-side components. | 1 | 200 | +| **14.3.4** | [ADDED, SPLIT FROM 4.3.2] Verify that directory browsing is disabled unless deliberately desired. | 1 | 548 | +| **14.3.5** | [ADDED, SPLIT FROM 4.3.2] Verify that the application does not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders. | 1 | | +| **14.3.6** | [GRAMMAR, MOVED FROM 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. | 1 | 552 | ## V14.4 HTTP Security Headers -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.4.1** | [MOVED TO 13.1.7] | | | | | -| **14.4.2** | [DELETED, MERGED TO 50.6.1] | | | | | -| **14.4.3** | [MOVED TO 50.3.1] | | | | | -| **14.4.4** | [MOVED TO 50.3.2] | | | | | -| **14.4.5** | [MOVED TO 50.3.3] | | | | | -| **14.4.6** | [MOVED TO 50.3.4] | | | | | -| **14.4.7** | [MOVED TO 50.3.5] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.4.1** | [MOVED TO 13.1.7] | | | +| **14.4.2** | [DELETED, MERGED TO 50.6.1] | | | +| **14.4.3** | [MOVED TO 50.3.1] | | | +| **14.4.4** | [MOVED TO 50.3.2] | | | +| **14.4.5** | [MOVED TO 50.3.3] | | | +| **14.4.6** | [MOVED TO 50.3.4] | | | +| **14.4.7** | [MOVED TO 50.3.5] | | | ## V14.5 HTTP Request Header Validation -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.5.1** | [MOVED TO 13.6.1] | | | | | -| **14.5.2** | [DELETED, COVERED BY 4.2.3] | | | | | -| **14.5.3** | [SPLIT TO 50.3.6, 50.4.3] | | | | | -| **14.5.4** | [DELETED, INCORRECT] | | | | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.5.1** | [MOVED TO 13.6.1] | | | +| **14.5.2** | [DELETED, COVERED BY 4.2.3] | | | +| **14.5.3** | [SPLIT TO 50.3.6, 50.4.3] | | | +| **14.5.4** | [DELETED, INCORRECT] | | | ## V14.6 Web or Application Server Configuration -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.6.1** | [GRAMMAR, MOVED FROM 12.6.1] Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from. | ✓ | ✓ | ✓ | 918 | -| **14.6.2** | [MODIFIED, MOVED FROM 1.2.1] Verify that communications between back-end application components, including local or operating system services, APIs, middleware and data layers, are performed with accounts assigned the least necessary privileges. | | ✓ | ✓ | 272 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.6.1** | [GRAMMAR, MOVED FROM 12.6.1] Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from. | 1 | 918 | +| **14.6.2** | [MODIFIED, MOVED FROM 1.2.1] Verify that communications between back-end application components, including local or operating system services, APIs, middleware and data layers, are performed with accounts assigned the least necessary privileges. | 2 | 272 | ## V14.7 External Service Configuration Applications need to interact with multiple external services including APIs, databases or other components. These might be considered internal to the application but not be included in the application's standard access control mechanisms or might be entirely external. In either case, it will be necessary to configure the application to interact securely with these components and, if necessary protect that configuration. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.7.1** | [MODIFIED, MOVED FROM 2.10.1, MERGED FROM 1.2.2] Verify that communications between back-end application components which don't support the application's standard user session mechanism, including APIs, middleware and data layers, are authenticated. Authentication should use individual service accounts, short-term tokens or certificate based authentication and not unchanging credentials such as passwords, API keys or shared accounts with privileged access. | | ✓ | ✓ | 287 | -| **14.7.2** | [GRAMMAR, MOVED FROM 2.10.2] Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g., root/root or admin/admin are default in some services during installation). | | ✓ | ✓ | 255 | -| **14.7.3** | [MODIFIED, MOVED FROM 4.3.3] Verify that, if the application allows changing configurations around passwords or connection parameters for integrations with external databases and services, they are protected by extra controls such as re-authentication or multi-user approval. | | ✓ | ✓ | 732 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.7.1** | [MODIFIED, MOVED FROM 2.10.1, MERGED FROM 1.2.2] Verify that communications between back-end application components which don't support the application's standard user session mechanism, including APIs, middleware and data layers, are authenticated. Authentication should use individual service accounts, short-term tokens or certificate based authentication and not unchanging credentials such as passwords, API keys or shared accounts with privileged access. | 2 | 287 | +| **14.7.2** | [GRAMMAR, MOVED FROM 2.10.2] Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g., root/root or admin/admin are default in some services during installation). | 2 | 255 | +| **14.7.3** | [MODIFIED, MOVED FROM 4.3.3] Verify that, if the application allows changing configurations around passwords or connection parameters for integrations with external databases and services, they are protected by extra controls such as re-authentication or multi-user approval. | 2 | 732 | ## V14.8 Secret Management Secret Management is a configuration task that is essential to ensure the protection of data being used in the application. Specific requirements on cryptography can be found in chapter V6 but this section focuses on the management and handling aspects of secrets. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **14.8.1** | [MODIFIED, MOVED FROM 6.4.1, MERGED FROM 1.6.2, 2.10.4, COVERS 2.10.3] Verify that a secrets management solution such as a key vault is used to securely create, store, control access to, and destroy back-end secrets. These could include passwords, key material, integrations with databases and third-party systems, seeds and internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For a L3 application, this should involve a hardware-backed solution such as an HSM. | | ✓ | ✓ | 798 | -| **14.8.2** | [MODIFIED, MOVED FROM 6.4.2] Verify that key material is not exposed to the application (neither the front-end nor the back-end) but instead uses an isolated security module like a vault for cryptographic operations. | | ✓ | ✓ | 320 | -| **14.8.3** | [ADDED] Verify that key secrets have defined expiration dates and are rotated on a schedule based on the organization’s threat model and business requirements. | | ✓ | ✓ | 320 | -| **14.8.4** | [ADDED] Verify that access to secret assets adheres to the principle of least privilege. | | ✓ | ✓ | 320 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **14.8.1** | [MODIFIED, MOVED FROM 6.4.1, MERGED FROM 1.6.2, 2.10.4, COVERS 2.10.3] Verify that a secrets management solution such as a key vault is used to securely create, store, control access to, and destroy back-end secrets. These could include passwords, key material, integrations with databases and third-party systems, seeds and internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For a L3 application, this should involve a hardware-backed solution such as an HSM. | 2 | 798 | +| **14.8.2** | [MODIFIED, MOVED FROM 6.4.2] Verify that key material is not exposed to the application (neither the front-end nor the back-end) but instead uses an isolated security module like a vault for cryptographic operations. | 2 | 320 | +| **14.8.3** | [ADDED] Verify that key secrets have defined expiration dates and are rotated on a schedule based on the organization’s threat model and business requirements. | 2 | 320 | +| **14.8.4** | [ADDED] Verify that access to secret assets adheres to the principle of least privilege. | 2 | 320 | ## References diff --git a/5.0/en/0x50-V50-Web-Frontend-Security.md b/5.0/en/0x50-V50-Web-Frontend-Security.md index 3668d3f86c..2f3d9f3e3e 100644 --- a/5.0/en/0x50-V50-Web-Frontend-Security.md +++ b/5.0/en/0x50-V50-Web-Frontend-Security.md @@ -6,41 +6,41 @@ The category focuses on requirements that protect against attacks that are execu Application documentation must specify required browser security features. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **1.50.1** | [ADDED] Verify that application documentation states the expected security features that browsers using the application should support (such as HTTPS, HSTS, Content Security Policy (CSP), and other relevant HTTP security mechanisms). It should also define how the application must behave when some of these features are not available (such as warning the user or blocking access). | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **1.50.1** | [ADDED] Verify that application documentation states the expected security features that browsers using the application should support (such as HTTPS, HSTS, Content Security Policy (CSP), and other relevant HTTP security mechanisms). It should also define how the application must behave when some of these features are not available (such as warning the user or blocking access). | 3 | | ## V50.1 Site Isolation Architecture To leverage the benefits of same-origin isolation, applications should be hosted on distinct hostnames. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.1.1** | [ADDED, DEPRECATES 3.4.5] Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies. | ✓ | ✓ | ✓ | 668 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.1.1** | [ADDED, DEPRECATES 3.4.5] Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies. | 1 | 668 | ## V50.2 Cookie Setup -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.2.1** | [MODIFIED, MOVED FROM 3.4.1] Verify that cookies have the 'Secure' attribute set, and if the '\__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name. | ✓ | ✓ | ✓ | 614 | -| **50.2.2** | [MODIFIED, MOVED FROM 3.4.2, LEVEL L1 > L2] Verify that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attribute set and the same value (e. g. session token) must only be transferred to the client via the 'Set-Cookie' header field. | | ✓ | ✓ | 1004 | -| **50.2.3** | [MODIFIED, MOVED FROM 3.4.3, LEVEL L1 > L2] Verify that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to cross-site request forgery and user interface redress attacks. | | ✓ | ✓ | 1275 | -| **50.2.4** | [MODIFIED, MOVED FROM 3.4.4, LEVEL L1 > L2] Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts. | | ✓ | ✓ | | -| **50.2.5** | [ADDED] Verify that when the application writes a cookie the cookie name and value length combined are not over 4096 bytes. Overly large cookies will not be stored by the browser and therefore not sent with requests, preventing the user from using application functionality which relies on that cookie. | | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.2.1** | [MODIFIED, MOVED FROM 3.4.1] Verify that cookies have the 'Secure' attribute set, and if the '\__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name. | 1 | 614 | +| **50.2.2** | [MODIFIED, MOVED FROM 3.4.2, LEVEL L1 > L2] Verify that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attribute set and the same value (e. g. session token) must only be transferred to the client via the 'Set-Cookie' header field. | 2 | 1004 | +| **50.2.3** | [MODIFIED, MOVED FROM 3.4.3, LEVEL L1 > L2] Verify that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to cross-site request forgery and user interface redress attacks. | 2 | 1275 | +| **50.2.4** | [MODIFIED, MOVED FROM 3.4.4, LEVEL L1 > L2] Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts. | 2 | | +| **50.2.5** | [ADDED] Verify that when the application writes a cookie the cookie name and value length combined are not over 4096 bytes. Overly large cookies will not be stored by the browser and therefore not sent with requests, preventing the user from using application functionality which relies on that cookie. | 2 | | ## V50.3 Browser Security Mechanism Headers HTTP responses must include security headers to set rules to how browsers can securely render content. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.3.1** | [MODIFIED, MOVED FROM 14.4.3, LEVEL L1 > L2] Verify that every HTTP response includes a Content-Security-Policy header to reduce the risk of malicious JavaScript. The directives object-src 'none' and base-uri 'none' must be defined. For an L3 application, a per-response policy with nonces or hashes must be defined. | | ✓ | ✓ | | -| **50.3.2** | [GRAMMAR, MOVED FROM 14.4.4] Verify that all responses contain a X-Content-Type-Options: nosniff header field. | ✓ | ✓ | ✓ | 116 | -| **50.3.3** | [MODIFIED, MOVED FROM 14.4.5] Verify that a Strict-Transport-Security header field is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains. | ✓ | ✓ | ✓ | 523 | -| **50.3.4** | [MODIFIED, MOVED FROM 14.4.6] Verify that an suitable Referrer-Policy header is included to prevent sensitive information in the URL from being exposed to untrusted parties via the Referer header. | ✓ | ✓ | ✓ | 116 | -| **50.3.5** | [MODIFIED, MOVED FROM 14.4.7] Verify that the content of the web application cannot be embedded in a third-party site by default, and that embedding of specific resources is allowed only when necessary, using the Content-Security-Policy frame-ancestors directive. Note that X-Frame-Options is now obsolete. | ✓ | ✓ | ✓ | 1021 | -| **50.3.6** | [ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is validated against an allowlist of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information. | ✓ | ✓ | ✓ | 183 | -| **50.3.7** | [ADDED] Verify that the Content-Security-Policy header field specifies a location to report violations. | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.3.1** | [MODIFIED, MOVED FROM 14.4.3, LEVEL L1 > L2] Verify that every HTTP response includes a Content-Security-Policy header to reduce the risk of malicious JavaScript. The directives object-src 'none' and base-uri 'none' must be defined. For an L3 application, a per-response policy with nonces or hashes must be defined. | 2 | | +| **50.3.2** | [GRAMMAR, MOVED FROM 14.4.4] Verify that all responses contain a X-Content-Type-Options: nosniff header field. | 1 | 116 | +| **50.3.3** | [MODIFIED, MOVED FROM 14.4.5] Verify that a Strict-Transport-Security header field is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains. | 1 | 523 | +| **50.3.4** | [MODIFIED, MOVED FROM 14.4.6] Verify that an suitable Referrer-Policy header is included to prevent sensitive information in the URL from being exposed to untrusted parties via the Referer header. | 1 | 116 | +| **50.3.5** | [MODIFIED, MOVED FROM 14.4.7] Verify that the content of the web application cannot be embedded in a third-party site by default, and that embedding of specific resources is allowed only when necessary, using the Content-Security-Policy frame-ancestors directive. Note that X-Frame-Options is now obsolete. | 1 | 1021 | +| **50.3.6** | [ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is validated against an allowlist of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information. | 1 | 183 | +| **50.3.7** | [ADDED] Verify that the Content-Security-Policy header field specifies a location to report violations. | 3 | | ## V50.4 Browser Origin Separation @@ -55,38 +55,38 @@ The category should contain requirements with ideas: * Verify that the request was initiated by a trusted party (CSRF, CORS misconfiguration) * Verify that the response is readable only for trusted parties (CORS misconfiguration) -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.4.1** | [MODIFIED, MOVED FROM 4.2.2, COVERS 13.2.3] Verify that CORS-safelisted requests to sensitive functionality are checked to ensure that they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP headers that are not CORS-safelisted request-headers. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | ✓ | ✓ | ✓ | 352 | -| **50.4.2** | [ADDED] Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid. | | ✓ | ✓ | 346 | -| **50.4.3** | [MODIFIED, MOVED FROM 13.2.5, SPLIT FROM 14.5.3, COVERS 13.2.3] Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a CORS-safelisted request. This may require checking the values of the 'Origin' and 'Content-Type' request headers or using an extra header field that is not CORS-safelisted. | ✓ | ✓ | ✓ | 346 | -| **50.4.4** | [MODIFIED, MOVED FROM 13.2.1] Verify that calls to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. This is particularly important if the application does not distinguish between URL parameters and message body parameters. | ✓ | ✓ | ✓ | 650 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.4.1** | [MODIFIED, MOVED FROM 4.2.2, COVERS 13.2.3] Verify that CORS-safelisted requests to sensitive functionality are checked to ensure that they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP headers that are not CORS-safelisted request-headers. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | 1 | 352 | +| **50.4.2** | [ADDED] Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid. | 2 | 346 | +| **50.4.3** | [MODIFIED, MOVED FROM 13.2.5, SPLIT FROM 14.5.3, COVERS 13.2.3] Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a CORS-safelisted request. This may require checking the values of the 'Origin' and 'Content-Type' request headers or using an extra header field that is not CORS-safelisted. | 1 | 346 | +| **50.4.4** | [MODIFIED, MOVED FROM 13.2.1] Verify that calls to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. This is particularly important if the application does not distinguish between URL parameters and message body parameters. | 1 | 650 | ## V50.5 Cross-Site Script Inclusion JSONP is an anti-pattern that can lead to data theft. Poor authorization in scripts that include sensitive data can lead to Cross-Site Script Inclusion (XSSI) attacks. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.5.1** | [ADDED] Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks. | ✓ | ✓ | ✓ | | -| **50.5.2** | [ADDED] Verify that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.5.1** | [ADDED] Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks. | 1 | | +| **50.5.2** | [ADDED] Verify that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks. | 1 | | ## V50.6 Unintended Content Interpretation Rendering content or functionality in an incorrect context can lead to a wide variety of security issues. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.6.1** | [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields, such as Sec-Fetch-\*, indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc. | ✓ | ✓ | ✓ | | -| **50.6.2** | [ADDED, SPLIT FROM 5.3.3] Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.6.1** | [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields, such as Sec-Fetch-\*, indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc. | 1 | | +| **50.6.2** | [ADDED, SPLIT FROM 5.3.3] Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript. | 1 | | ## V50.7 External Resource Integrity Hosting content on third-party sites can lead to malicious content modification and supply chain attacks. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.7.1** | [MODIFIED, MOVED FROM 14.2.3] Verify that if client-side assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. | ✓ | ✓ | ✓ | 829 | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.7.1** | [MODIFIED, MOVED FROM 14.2.3] Verify that if client-side assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. | 1 | 829 | ## V50.8 Other Browser Security Considerations @@ -94,12 +94,12 @@ Hosting content on third-party sites can lead to malicious content modification it may need other separate section for "end-user protection via UI" --> -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **50.8.1** | [ADDED, SPLIT FROM 5.1.5] Verify that the application shows a notification when the user is being redirected to a URL outside of the application's control, with an option to cancel the navigation. | | | ✓ | | -| **50.8.2** | [MODIFIED, MOVED FROM 1.14.6] Verify that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | | ✓ | ✓ | 477 | -| **50.8.3** | [ADDED] Verify that the application behaves as documented (such as warning the user or blocking access) if the browser used to access the application does not support the expected security features. | | | ✓ | | -| **50.8.4** | [ADDED] Verify that the application's top-level domain (e.g., site.tld) is added to the public HSTS preload list so that the use of TLS for the application is built directly into the main browsers, rather than relying only on the relevant HTTP response header field. | | | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **50.8.1** | [ADDED, SPLIT FROM 5.1.5] Verify that the application shows a notification when the user is being redirected to a URL outside of the application's control, with an option to cancel the navigation. | 3 | | +| **50.8.2** | [MODIFIED, MOVED FROM 1.14.6] Verify that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | 2 | 477 | +| **50.8.3** | [ADDED] Verify that the application behaves as documented (such as warning the user or blocking access) if the browser used to access the application does not support the expected security features. | 3 | | +| **50.8.4** | [ADDED] Verify that the application's top-level domain (e.g., site.tld) is added to the public HSTS preload list so that the use of TLS for the application is built directly into the main browsers, rather than relying only on the relevant HTTP response header field. | 3 | | ## References diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index f89629ea96..33ab66aa66 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -46,10 +46,10 @@ The risk levels for some of the requirements in this chapter depend on whether t These requirements cover generic architectural requirements that apply to all applications using OAuth or OIDC, such as key architectural patterns available when building browser-based JavaScript applications that rely on OAuth or OIDC for accessing protected resources. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **51.1.1** | [ADDED] Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend. | ✓ | ✓ | ✓ | -| **51.1.2** | [ADDED] Verify that the client only accepts values from the authorization server (such as the authorization code or ID token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce' are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | ✓ | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **51.1.1** | [ADDED] Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend. | 1 | +| **51.1.2** | [ADDED] Verify that the client only accepts values from the authorization server (such as the authorization code or ID token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce' are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | 1 | ## V51.2 OAuth Client @@ -57,11 +57,11 @@ These requirements detail the responsibilities for OAuth client applications. Th In general, backend clients are regarded as confidential clients and frontend clients are regarded as public clients. However, native applications running on the end user device can be regarded as confidential when using OAuth dynamic client registration. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **51.2.1** | [ADDED] Verify that, if the OAuth Client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require that the authorization server returns the 'iss' parameter value and validate it in the authorization response and the token response. | ✓ | ✓ | ✓ | -| **51.2.2** | [ADDED] Verify that, if the code flow is used, the OAuth Client has protection against cross-site request forgery (CSRF) attacks which trigger token requests, either by using proof key for code exchange (PKCE) functionality or checking the 'state' parameter that was sent in the authorization request. | ✓ | ✓ | ✓ | -| **51.2.3** | [ADDED] Verify that the OAuth Client only requests the required scopes (or other authorization parameters) in requests to the authorization server. | ✓ | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **51.2.1** | [ADDED] Verify that, if the OAuth Client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require that the authorization server returns the 'iss' parameter value and validate it in the authorization response and the token response. | 1 | +| **51.2.2** | [ADDED] Verify that, if the code flow is used, the OAuth Client has protection against cross-site request forgery (CSRF) attacks which trigger token requests, either by using proof key for code exchange (PKCE) functionality or checking the 'state' parameter that was sent in the authorization request. | 1 | +| **51.2.3** | [ADDED] Verify that the OAuth Client only requests the required scopes (or other authorization parameters) in requests to the authorization server. | 1 | ## V51.3 OAuth Resource Server @@ -72,46 +72,46 @@ In the context of ASVS and this chapter, the resource server is an API. To provi Therefore, the requirements listed here are OAuth or OIDC specific and should be performed after token validation and before performing authorization based on information from the token. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **51.3.1** | [ADDED] Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP). | | | ✓ | -| **51.3.2** | [ADDED] Verify that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structured access token (such as the 'aud' claim in JWT) or it can be checked using the token introspection endpoint. | ✓ | ✓ | ✓ | -| **51.3.3** | [ADDED] Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they should be part of the decision. | ✓ | ✓ | ✓ | -| **51.3.4** | [ADDED] Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that can not be reassigned to other users. Typically it means using a combination of 'iss' and 'sub' claims. | ✓ | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **51.3.1** | [ADDED] Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP). | 3 | +| **51.3.2** | [ADDED] Verify that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structured access token (such as the 'aud' claim in JWT) or it can be checked using the token introspection endpoint. | 1 | +| **51.3.3** | [ADDED] Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they should be part of the decision. | 1 | +| **51.3.4** | [ADDED] Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that can not be reassigned to other users. Typically it means using a combination of 'iss' and 'sub' claims. | 1 | ## V51.4 OAuth Authorization Server These requirements detail the responsibilities for OAuth authorization servers, including OpenID providers. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **51.4.1** | [ADDED] Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code. | ✓ | ✓ | ✓ | -| **51.4.2** | [ADDED] Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications. | ✓ | ✓ | ✓ | -| **51.4.3** | [ADDED] Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept 'code_challenge_method' value 'plain'. For a token request, it must require validation of the 'code_verifier' parameter. | ✓ | ✓ | ✓ | -| **51.4.4** | [ADDED] Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens (i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS)). For L1 applications only, refresh token rotation may be used instead. If refresh token rotation is used, verify that the authorization server invalidates the refresh token after usage and revokes all refresh tokens for that authorization if an already used and invalidated refresh token is provided. | ✓ | ✓ | ✓ | -| **51.4.5** | [ADDED] Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used. | | ✓ | ✓ | -| **51.4.6** | [ADDED] Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | ✓ | ✓ | ✓ | -| **51.4.7** | [ADDED] Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), token revocation requests, and token introspection requests. | ✓ | ✓ | ✓ | -| **51.4.8** | [ADDED] Verify that the authorization server configuration only assigns the required scopes to the OAuth Client. | ✓ | ✓ | ✓ | -| **51.4.9** | [ADDED] Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | | | ✓ | -| **51.4.10** | [ADDED] Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), i.e., 'mTLS' or 'private-key-jwt'. | | | ✓ | -| **51.4.11** | [ADDED] Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either using mTLS certificate binding or Demonstration of Proof of Possession (DPoP). | | | ✓ | -| **51.4.12** | [ADDED] Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured authorization request (JAR). | ✓ | ✓ | ✓ | -| **51.4.13** | [ADDED] Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | ✓ | ✓ | ✓ | -| **51.4.14** | [MODIFIED, MOVED FROM 3.5.1] Verify that refresh tokens and reference access tokens can be revoked by an authorized user. It can be achieved by using the authorization server user interface, or by a client that is using authorization server APIs for revocation. | | ✓ | ✓ | -| **51.4.15** | [ADDED] Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example by requiring the usage of pushed authorization request (PAR) or JWT-secured authorization request (JAR). | | | ✓ | -| **51.4.16** | [ADDED] Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent and warn the user before processing an authorization request with an untrusted client application. | | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **51.4.1** | [ADDED] Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code. | 1 | +| **51.4.2** | [ADDED] Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications. | 1 | +| **51.4.3** | [ADDED] Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept 'code_challenge_method' value 'plain'. For a token request, it must require validation of the 'code_verifier' parameter. | 1 | +| **51.4.4** | [ADDED] Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens (i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS)). For L1 applications only, refresh token rotation may be used instead. If refresh token rotation is used, verify that the authorization server invalidates the refresh token after usage and revokes all refresh tokens for that authorization if an already used and invalidated refresh token is provided. | 1 | +| **51.4.5** | [ADDED] Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used. | 2 | +| **51.4.6** | [ADDED] Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | 1 | +| **51.4.7** | [ADDED] Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), token revocation requests, and token introspection requests. | 1 | +| **51.4.8** | [ADDED] Verify that the authorization server configuration only assigns the required scopes to the OAuth Client. | 1 | +| **51.4.9** | [ADDED] Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | 3 | +| **51.4.10** | [ADDED] Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), i.e., 'mTLS' or 'private-key-jwt'. | 3 | +| **51.4.11** | [ADDED] Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either using mTLS certificate binding or Demonstration of Proof of Possession (DPoP). | 3 | +| **51.4.12** | [ADDED] Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured authorization request (JAR). | 1 | +| **51.4.13** | [ADDED] Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | 1 | +| **51.4.14** | [MODIFIED, MOVED FROM 3.5.1] Verify that refresh tokens and reference access tokens can be revoked by an authorized user. It can be achieved by using the authorization server user interface, or by a client that is using authorization server APIs for revocation. | 2 | +| **51.4.15** | [ADDED] Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example by requiring the usage of pushed authorization request (PAR) or JWT-secured authorization request (JAR). | 3 | +| **51.4.16** | [ADDED] Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent and warn the user before processing an authorization request with an untrusted client application. | 2 | ## V51.5 OIDC Client As the OIDC Relying Party acts as an OAuth client, the requirements from the section "OAuth Client" apply as well. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **51.5.1** | [ADDED] Verify that the Client (as the relying party) mitigates ID token replay attacks. For example, by ensuring that the 'nonce' claim in the ID token matches the 'nonce' value sent in the authentication request to the OpenID provider (in OAuth2 refereed to as the authorization request sent to the authorization server). | ✓ | ✓ | ✓ | -| **51.5.2** | [ADDED] Verify that the Client uniquely identifies the user from ID token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope of an identity provider). | ✓ | ✓ | ✓ | -| **51.5.3** | [ADDED] Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the pre-configured issuer URL expected by client. | ✓ | ✓ | ✓ | -| **51.5.4** | [ADDED] Verify that the client validates that the ID token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal to the 'client_id' value for the client. | ✓ | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **51.5.1** | [ADDED] Verify that the Client (as the relying party) mitigates ID token replay attacks. For example, by ensuring that the 'nonce' claim in the ID token matches the 'nonce' value sent in the authentication request to the OpenID provider (in OAuth2 refereed to as the authorization request sent to the authorization server). | 1 | +| **51.5.2** | [ADDED] Verify that the Client uniquely identifies the user from ID token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope of an identity provider). | 1 | +| **51.5.3** | [ADDED] Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the pre-configured issuer URL expected by client. | 1 | +| **51.5.4** | [ADDED] Verify that the client validates that the ID token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal to the 'client_id' value for the client. | 1 | ## V51.6 OpenID Provider @@ -119,17 +119,17 @@ As OpenID Providers act as OAuth Authorization servers, the requirements from th Note that if using the id-token flow (not the code flow), no access tokens are issued and many of the requirements for OAuth AS are not applicable. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **51.6.1** | [ADDED] Verify that the OpenID Provider only allows values 'code', 'ciba', 'id-token', or 'id-token code' for response mode. Note that 'code' is preferred over 'id-token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must not be used. | | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **51.6.1** | [ADDED] Verify that the OpenID Provider only allows values 'code', 'ciba', 'id-token', or 'id-token code' for response mode. Note that 'code' is preferred over 'id-token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must not be used. | 2 | ## V51.7 Consent Management -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **51.7.1** | [ADDED] Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent. | | ✓ | ✓ | -| **51.7.2** | [ADDED] Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable this should include the nature of the requested authorizations (typically based on scope, resource server, rich authorization requests (RAR) authorization details), the identity of the authorized application and the lifetime of these authorizations. | | ✓ | ✓ | -| **51.7.3** | [ADDED] Verify that the user can review, modify and revoke consents which the user has granted through the authorization server. | | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **51.7.1** | [ADDED] Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent. | 2 | +| **51.7.2** | [ADDED] Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable this should include the nature of the requested authorizations (typically based on scope, resource server, rich authorization requests (RAR) authorization details), the identity of the authorized application and the lifetime of these authorizations. | 2 | +| **51.7.3** | [ADDED] Verify that the user can review, modify and revoke consents which the user has granted through the authorization server. | 2 | ## References diff --git a/5.0/en/0x52-V52-Tokens.md b/5.0/en/0x52-V52-Tokens.md index 8cbdd794a4..9d05382c66 100644 --- a/5.0/en/0x52-V52-Tokens.md +++ b/5.0/en/0x52-V52-Tokens.md @@ -10,11 +10,11 @@ The use of self-contained tokens has become very widespread, even outside of OID Before inspecting the contents of a self-contained token, it is necessary to ensure that the token has been produced by a trusted party and that it has not been tampered with. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **52.1.1** | [MODIFIED, MOVED FROM 3.5.3, LEVEL L2 > L1] Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | ✓ | ✓ | ✓ | 345 | -| **52.1.2** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | ✓ | ✓ | ✓ | 757 | -| **52.1.3** | [ADDED] Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **52.1.1** | [MODIFIED, MOVED FROM 3.5.3, LEVEL L2 > L1] Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | 1 | 345 | +| **52.1.2** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | 1 | 757 | +| **52.1.3** | [ADDED] Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | 1 | | ## V52.2 Using token content @@ -22,11 +22,11 @@ Before making security decisions based on the content of a self-contained token, Specific requirements for OAuth and OIDC are covered in the dedicated chapter. -| # | Description | L1 | L2 | L3 | CWE | -| :---: | :--- | :---: | :---: | :---: | :---: | -| **52.2.1** | [ADDED] Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs the claims 'nbf' and 'exp' must be verified. | ✓ | ✓ | ✓ | 613 | -| **52.2.2** | [ADDED] Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID tokens can be used for proving user authentication. | ✓ | ✓ | ✓ | | -| **52.2.3** | [ADDED] Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service. | ✓ | ✓ | ✓ | | +| # | Description | Level | CWE | +| :---: | :--- | :---: | :---: | +| **52.2.1** | [ADDED] Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs the claims 'nbf' and 'exp' must be verified. | 1 | 613 | +| **52.2.2** | [ADDED] Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID tokens can be used for proving user authentication. | 1 | | +| **52.2.3** | [ADDED] Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service. | 1 | | ## References diff --git a/5.0/en/0x53-V53-WebRTC.md b/5.0/en/0x53-V53-WebRTC.md index a0be8e1294..671c01c03f 100644 --- a/5.0/en/0x53-V53-WebRTC.md +++ b/5.0/en/0x53-V53-WebRTC.md @@ -26,10 +26,10 @@ Traversal Using Relays around NAT (TURN) servers play a crucial role in WebRTC a These requirements only apply to systems that host TURN servers as part of their WebRTC infrastructure. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **53.1.1** | [ADDED] Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses. | ✓ | ✓ | ✓ | -| **53.1.2** | [ADDED] Verify that the Traversal Using Relays around NAT (TURN) service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server. | | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **53.1.1** | [ADDED] Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses. | 1 | +| **53.1.2** | [ADDED] Verify that the Traversal Using Relays around NAT (TURN) service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server. | 2 | ## V53.2 Media @@ -41,16 +41,16 @@ In particular, it will be necessary to implement protections against flood attac Systems that rely solely on peer-to-peer media communication between web browsers, without the involvement of intermediate media servers, are excluded from these specific media-related security requirements. However, such systems should still adhere to the other requirements outlined in this chapter to ensure the overall security of their communications. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **53.2.1** | [ADDED] Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is private by ensuring it is not reused in existing products or open-source projects and confirming it is not distributed or leaked. | ✓ | ✓ | ✓ | -| **53.2.2** | [ADDED] Verify that the media server is configured to use and support strong and secure DTLS cipher suites and DTLS-SRTP protection profiles. | ✓ | ✓ | ✓ | -| **53.2.3** | [ADDED] Verify that the media server is not susceptible to the "WebRTC DTLS ClientHello Race Condition" vulnerability by checking if the media server is publicly known to be vulnerable or by performing the race condition test. | | ✓ | ✓ | -| **53.2.4** | [ADDED] Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media server to prevent Real-time Transport Protocol (RTP) injection attacks from leading to either a Denial of Service condition or audio or video media insertion into media streams. | ✓ | ✓ | ✓ | -| **53.2.5** | [ADDED] Verify that the media server is able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | | ✓ | ✓ | -| **53.2.6** | [ADDED] Verify that any audio or video recording mechanisms associated with the media server are able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | | ✓ | ✓ | -| **53.2.7** | [ADDED] Verify that the media server is able to continue processing incoming media traffic when encountering malformed SRTP packets. | | ✓ | ✓ | -| **53.2.8** | [ADDED] Verify that the DTLS certificate is checked against the SDP fingerprint attribute, terminating the media stream if the check fails, to ensure the authenticity of the media stream. | ✓ | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **53.2.1** | [ADDED] Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is private by ensuring it is not reused in existing products or open-source projects and confirming it is not distributed or leaked. | 1 | +| **53.2.2** | [ADDED] Verify that the media server is configured to use and support strong and secure DTLS cipher suites and DTLS-SRTP protection profiles. | 1 | +| **53.2.3** | [ADDED] Verify that the media server is not susceptible to the "WebRTC DTLS ClientHello Race Condition" vulnerability by checking if the media server is publicly known to be vulnerable or by performing the race condition test. | 2 | +| **53.2.4** | [ADDED] Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media server to prevent Real-time Transport Protocol (RTP) injection attacks from leading to either a Denial of Service condition or audio or video media insertion into media streams. | 1 | +| **53.2.5** | [ADDED] Verify that the media server is able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 2 | +| **53.2.6** | [ADDED] Verify that any audio or video recording mechanisms associated with the media server are able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 2 | +| **53.2.7** | [ADDED] Verify that the media server is able to continue processing incoming media traffic when encountering malformed SRTP packets. | 2 | +| **53.2.8** | [ADDED] Verify that the DTLS certificate is checked against the SDP fingerprint attribute, terminating the media stream if the check fails, to ensure the authenticity of the media stream. | 1 | ## V53.3 Signalling @@ -58,10 +58,10 @@ Signalling is a critical component of WebRTC applications, responsible for coord These requirements only apply to systems that host signalling servers as part of their WebRTC infrastructure. -| # | Description | L1 | L2 | L3 | -| :---: | :--- | :---: | :---: | :---: | -| **53.3.1** | [ADDED] Verify that the signalling server is able to continue processing incoming signalling messages during a flood attack. This should be achieved by implementing rate limiting at the signalling level. | | ✓ | ✓ | -| **53.3.2** | [ADDED] Verify that the signalling server is able to is able to continue processing signalling messages when encountering malformed signalling messages. | | ✓ | ✓ | +| # | Description | Level | +| :---: | :--- | :---: | +| **53.3.1** | [ADDED] Verify that the signalling server is able to continue processing incoming signalling messages during a flood attack. This should be achieved by implementing rate limiting at the signalling level. | 2 | +| **53.3.2** | [ADDED] Verify that the signalling server is able to is able to continue processing signalling messages when encountering malformed signalling messages. | 2 | ## References