Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#2456 step 2.4 renumber everything #2804

Merged
merged 2 commits into from
Mar 27, 2025
Merged

#2456 step 2.4 renumber everything #2804

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ceeede9
#2553, #2456 step 2.4 - renumbering titles
Mar 27, 2025
9ae401b
#2553, #2456 step 2.4 - renumbering requirements
Mar 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 37 additions & 37 deletions 5.0/en/0x10-V1-Encoding-Sanitization.md
View file
Open in desktop

Large diffs are not rendered by default.

34 changes: 17 additions & 17 deletions 5.0/en/0x11-V2-Business-Logic.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# V11 Business Logic
# V2 Business Logic

## Control Objective

Expand All @@ -8,17 +8,17 @@ Ensure that a verified application satisfies the following high-level requiremen
* Business logic includes limits and controls to detect and prevent automated attacks, such as continuous small funds transfers and adding a million friends one at a time.
* High-value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks.

## V1.11 Business Logic Documentation
## V2.1 Business Logic Documentation

Business logic documentation should clearly define business logic limits, validation rules, and contextual consistency of combined data items so that it is clear what needs to be implemented in the application.

| # | Description | Level | #v5.0.be |
| :---: | :--- | :---: | :---: |
| **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 | v5.0.be-1.11.6 |
| **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 | v5.0.be-1.11.5 |
| **1.11.4** | [ADDED] Verify that expectations for business logic limits and validations are documented including both per-user and also globally across the application. | 2 | v5.0.be-1.11.4 |
| **2.1.1** | [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 | v5.0.be-1.11.6 |
| **2.1.2** | [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 | v5.0.be-1.11.5 |
| **2.1.3** | [ADDED] Verify that expectations for business logic limits and validations are documented including both per-user and also globally across the application. | 2 | v5.0.be-1.11.4 |

## V11.3 Input Validation
## V2.2 Input Validation

Properly implemented input validation controls, using positive allowlists and strong data typing, provide an important enforcement of business logic controls or functional expectations around the type of data that the app expects to receive.

Expand All @@ -36,29 +36,29 @@ Input validation provides valuable hygiene for the application in making sure th

| # | Description | Level | #v5.0.be |
| :---: | :--- | :---: | :---: |
| **11.3.1** | [MODIFIED, MOVED FROM 5.1.3, SPLIT FROM 5.1.4, MERGED FROM 11.1.5, COVERS 13.2.2, 13.3.1] Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allowed list of values, patterns or ranges or alternatively be based on comparing to an expected structure or logical limit, according to pre-defined rules. For L1 this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input. | 1 | v5.0.be-11.3.1 |
| **11.3.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. | 1 | v5.0.be-11.3.2 |
| **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 | v5.0.be-11.3.3 |
| **2.2.1** | [MODIFIED, MOVED FROM 5.1.3, SPLIT FROM 5.1.4, MERGED FROM 11.1.5, COVERS 13.2.2, 13.3.1] Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allowed list of values, patterns or ranges or alternatively be based on comparing to an expected structure or logical limit, according to pre-defined rules. For L1 this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input. | 1 | v5.0.be-11.3.1 |
| **2.2.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. | 1 | v5.0.be-11.3.2 |
| **2.2.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 | v5.0.be-11.3.3 |

## V11.1 Business Logic Security
## V2.3 Business Logic Security

This section considers key requirements to ensure that the application enforces business logic processes in the correct way and is not vulnerable to attacks that exploit the logic and flow of the application.

| # | Description | Level | #v5.0.be |
| :---: | :--- | :---: | :---: |
| **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 | v5.0.be-11.1.1 |
| **11.1.3** | [MODIFIED] Verify that business logic limits are implemented as per the application's documentation, to avoid business logic flaws being exploited. | 2 | v5.0.be-11.1.3 |
| **11.1.9** | [ADDED] Verify that 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 | v5.0.be-11.1.9 |
| **11.1.10** | [ADDED] Verify that 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 | v5.0.be-11.1.10 |
| **2.3.1** | Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps. | 1 | v5.0.be-11.1.1 |
| **2.3.2** | [MODIFIED] Verify that business logic limits are implemented as per the application's documentation, to avoid business logic flaws being exploited. | 2 | v5.0.be-11.1.3 |
| **2.3.3** | [ADDED] Verify that 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 | v5.0.be-11.1.9 |
| **2.3.4** | [ADDED] Verify that 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 | v5.0.be-11.1.10 |

## V11.2 Anti-automation
## V2.4 Anti-automation

This section includes anti-automation controls to ensure that human-like interactions are required and excessive automated requests are prevented.

| # | Description | Level | #v5.0.be |
| :---: | :--- | :---: | :---: |
| **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 | v5.0.be-11.2.2 |
| **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 | v5.0.be-11.2.1 |
| **2.4.1** | [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 | v5.0.be-11.2.2 |
| **2.4.2** | [MODIFIED, MOVED FROM 11.1.2, LEVEL L1 > L3] Verify that business logic processes require realistic human timing, preventing excessively rapid transaction submissions. | 3 | v5.0.be-11.2.1 |

## References

Expand Down
Loading