+V2 Validation and Business Logic
---+V2.1 Validation and Business Logic Documentation
------+V2.1.1 Verify that the application's documentation defines input validation rules for how to check the …
------+V2.1.2 Verify that the application's documentation defines how to validate the logical and contextual …
------+V2.1.3 Verify that expectations for business logic limits and validations are documented, including both …
---+V2.2 Input Validation
------+V2.2.1 Verify that input is validated to enforce business or functional expectations for that input. This …
------+V2.2.2 Verify that the application is designed to enforce input validation at a trusted service layer. …
------+V2.2.3 Verify that the application ensures that combinations of related data items are reasonable …
---+V2.3 Business Logic Security
------+V2.3.1 Verify that the application will only process business logic flows for the same user in the …
------+V2.3.2 Verify that business logic limits are implemented per the application's documentation to avoid …
------+V2.3.3 Verify that transactions are being used at the business logic level such that either a business …
------+V2.3.4 Verify that business logic level locking mechanisms are used to ensure that limited quantity …
------+V2.3.5 Verify that high-value business logic flows require multi-user approval to prevent unauthorized or …
---+V2.4 Anti-automation
------+V2.4.1 Verify that anti-automation controls are in place to protect against excessive calls to application …
------+V2.4.2 Verify that business logic flows require realistic human timing, preventing excessively rapid …

V2 Validation and Business Logic

Control Objective

This chapter aims to ensure that a verified application meets the following high-level goals:

  • Input received by the application matches business or functional expectations.
  • The business logic flow is sequential, processed in order, and cannot be bypassed.
  • Business logic includes limits and controls to detect and prevent automated attacks, such as continuous small funds transfers or 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.

References

For more information, see also:

1. Panoramica

V2.1 Validation and Business Logic Documentation

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

Effective input validation controls enforce business or functional expectations around the type of data the application expects to receive. This ensures good data quality and reduces the attack surface. However, it does not remove or replace the need to use correct encoding, parameterization, or sanitization when using the data in another component or for presenting it for output.

In this context, "input" 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.

A business logic control might check that a particular input is a number less than 100. A functional expectation might check that a number is below a certain threshold, as that number controls how many times a particular loop will take place, and a high number could lead to excessive processing and a potential denial of service condition.

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.

Please note the following points on Schema Validation:

  • 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 below.
  • Any JSON Schema validation libraries in use should also 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.
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.
V2.4 Anti-automation

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

1.1 Riferimenti

1.2 Requisiti identificati

1.3 Regolamentazioni correlate

2. Requisiti identificati

Requisiti

3. Regolamentazioni correlate

Regolamentazioni
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.