diff --git a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md index 49bd3d48a6..fc14920727 100644 --- a/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md +++ b/5.0/en/0x13-V5-Validation-Sanitization-Encoding.md @@ -18,11 +18,10 @@ The "untrusted client" term here refers to client-side technologies that render | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **1.5.1** | [MODIFIED, SPLIT TO 1.5.5, 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.5.1** | [SPLIT TO 1.11.5, 1.11.6] | | | | | | **1.5.2** | [DELETED, MERGED TO 5.5.3] | | | | | -| **1.5.3** | [MOVED TO 5.6.2] | | | | | -| **1.5.4** | [MOVED TO 5.6.3] | | | | | -| **1.5.5** | [ADDED, SPLIT FROM 1.5.1] 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 | +| **1.5.3** | [MOVED TO 11.3.4] | | | | | +| **1.5.4** | [MOVED TO 5.6.2] | | | | | ## V5.1 Input Validation @@ -34,13 +33,12 @@ Input validation provides valuable hygiene for the application in making sure th | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **5.1.1** | [MODIFIED] 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 | +| **5.1.1** | [MOVED TO 10.4.7] | | | | | | **5.1.2** | [MOVED TO 10.4.4] | | | | | -| **5.1.3** | [MODIFIED] Verify that all input is validated using positive validation, against an allowed list of values, patterns or ranges to enforce business or functional expectations for that input. | ✓ | ✓ | ✓ | 20 | -| **5.1.4** | [MODIFIED, SPLIT TO 5.1.7] Verify that data items with an expected structure are validated according to the pre-defined rules. | ✓ | ✓ | ✓ | 20 | +| **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. | | ✓ | ✓ | | -| **5.1.7** | [ADDED, SPLIT FROM 5.1.4] Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | ✓ | ✓ | ✓ | 20 | ## V5.2 Sanitization and Sandboxing @@ -133,8 +131,7 @@ 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.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 | -| **5.6.3** | [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 | +| **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 | ## References diff --git a/5.0/en/0x18-V10-Coding.md b/5.0/en/0x18-V10-Coding.md index 8fe54a2ad0..355568a806 100644 --- a/5.0/en/0x18-V10-Coding.md +++ b/5.0/en/0x18-V10-Coding.md @@ -62,6 +62,7 @@ Complying with this section is likely to be operational and continuous. | **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.5 Security Architecture diff --git a/5.0/en/0x19-V11-BusLogic.md b/5.0/en/0x19-V11-BusLogic.md index 900878c393..6947ad3ef1 100644 --- a/5.0/en/0x19-V11-BusLogic.md +++ b/5.0/en/0x19-V11-BusLogic.md @@ -16,6 +16,8 @@ Ensure that a verified application satisfies the following high-level requiremen | **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 | ## V11.1 Business Logic Security @@ -41,6 +43,15 @@ Business logic security is so individual to every application that no one checkl | **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 | +## 11.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 | + ## References For more information, see also: