asvs/v2-validation-and-business-logic

17 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V2.1.1 Input validation rules documentation

Requirement 2.1.1 (Level 1): Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, email addresses, telephone numbers, or it could be an internal data format.

V2.1.2 Logical and contextual consistency documentation

Requirement 2.1.2 (Level 2): Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that suburb and ZIP code match.

V2.1.3 Business logic limits and validations documentation

Requirement 2.1.3 (Level 2): Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application.

V2.2.1 Input validation against business or functional expectations

Requirement 2.2.1 (Level 1): Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined 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.

V2.2.2 Input validation at trusted service layer

Requirement 2.2.2 (Level 1): Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be encouraged, it must not be relied upon as a security control.

V2.2.3 Validation of related data combinations

Requirement 2.2.3 (Level 2): Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules.

V2.3.1 Sequential business logic flow enforcement

Requirement 2.3.1 (Level 1): Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps.

V2.3.2 Business logic limits implementation

Requirement 2.3.2 (Level 2): Verify that business logic limits are implemented per the application's documentation to avoid business logic flaws being exploited.

V2.3.3 Transactions for business logic operations

Requirement 2.3.3 (Level 2): 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.

V2.3.4 Business logic level locking for resource availability

Requirement 2.3.4 (Level 2): Verify that business logic level locking mechanisms are used to ensure that limited quantity resources (such as theater seats or delivery slots) cannot be double-booked by manipulating the application's logic.

V2.3.5 Multi-user approval for high-value business logic

Requirement 2.3.5 (Level 3): Verify that high-value business logic flows require multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to classified information, or safety overrides in manufacturing.

V2.4.1 Anti-automation controls

Requirement 2.4.1 (Level 2): 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.

V2.4.2 Realistic human timing for business logic flows

Requirement 2.4.2 (Level 3): Verify that business logic flows require realistic human timing, preventing excessively rapid transaction submissions.

Schema validation guidance - JSON Schema and DTD

While schema validation is not explicitly mandated, it may be the most effective mechanism for full validation coverage of HTTP APIs or other interfaces that use JSON or XML. The published version of the JSON Schema validation specification is considered production-ready but not strictly speaking stable. When using JSON Schema validation, ensure there are no gaps with the guidance in the requirements. Any JSON Schema validation libraries in use should be monitored and updated if necessary once the standard is formalized. DTD validation should not be used, and framework DTD evaluation should be disabled, to avoid issues with XXE attacks against DTDs.

Input sources in application context

Input in the context of validation and business logic could come from a wide variety of sources, including HTML form fields, REST requests, URL parameters, HTTP header fields, cookies, files on disk, databases, and external APIs.

ASVS chapter 2 requirements and NIST mappings

ASVS chapter 2 requirements are mapped to NIST sections as follows: 2.1.1 through 2.1.14 cover authentication topics, with most mapping to NIST 5.1.1.2 (2.1.4 and 2.1.8 have no mapping); 2.2.1 through 2.2.11 cover session management with mappings to NIST 5.2.2, 6.1.2, 4.3.1, 4.2.1 and several unmapped; 2.3.1 through 2.3.4 cover password management with mappings to NIST 5.1.1.2/A.3, 6.1.4 and unmapped entries; 2.4.1 through 2.4.6 and 2.5.1 through 2.5.7 cover additional authentication topics with scattered NIST mappings; 2.6.1 through 2.6.4 map to NIST 5.1.2.1 and 5.1.2.2; 2.7.1 through 2.7.8 cover session lifecycle with mappings to NIST 5.1.3.2, 5.1.3.3, 5.2.10; 2.8.1 through 2.8.8 map to NIST 5.1.4.2/5.1.5.2, 5.2.1, 5.2.3; 2.9.1 through 2.9.3 map to NIST 5.1.7.2; 2.10.1 through 2.11.3 have no NIST mappings.

Client-side input validation recommendation

Client-side input validation should be enforced in addition to validation at a trusted service layer as this provides a good opportunity to discover when someone has bypassed client-side controls in an attempt to attack the application. This is an in-scope recommendation for ASVS 5.0.

Give your agent this brain