Data Validation & Encoding (VE6)
Jason can bypass the centralized validation routines since they are not being used on all inputs
This card relates to bypass of input data validation. See Data Validation & Encoding 5 for the similar bypass of output encoding.
Scenario: Jason’s Validation Evasion
Imagine a scenario where Jason, exploiting system weaknesses, bypasses security measures due to inconsistent application of centralized validation routines. He takes advantage of the system's oversight in the following way:
- Inconsistent Application of Validation: The system fails to use centralized validation routines on all input sources.
Example
Jason discovers that while most input fields on your web application are properly validated, certain API endpoints or secondary input forms lack the same rigorous validation. He targets these overlooked areas, submitting malicious data that would normally be caught and neutralized by the centralized validation routines. This allows him to inject harmful data or commands into the system.
Threat Modeling
STRIDE
This scenario falls squarely into the Tampering category of STRIDE. By bypassing centralized validation routines, Jason is able to inject malicious or malformed input (e.g., code injection, buffer overflow payloads) that alters how the system processes the data. The core issue is that unchecked input lets him tamper with the system’s expected data flows and behavior. Elevation of Privilege could be a consequence (e.g., RCE via injection), but the root threat is tampering with input.
What can go wrong?
Such lapses in validation can lead to severe security breaches, including data corruption, unauthorized access, and other forms of system compromise. Common attacks to bad implementation (or lack) of validation routines are:
- Buffer overflows.
- Code injection.
- Fuzzing.
For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.
What are we going to do about it?
Centralized input validation routines are a good programming practice, but like other routines, developers need to understand how they work, how to use them and any limitations. Such routines can be tested independently of other code and not only provide assurance on the quality of the input validation, but it make refactorization an easy task and eliminate code duplicates and bad interpretations. Use of white list validation is recommended where possible. Black lists are usually good as a double-check complement, as they can trigger alerts for fake positives. If third-party input validation libraries are used, it is important to test each routine before its implementation.
- Ensure that centralized validation routines are uniformly applied to all input sources, including web forms, APIs, and any other data entry points.
- Regularly audit and update validation protocols to cover all potential avenues of data input.
For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.
Mappings
STRIDE: Tampering
OWASP ASVS: 1.4.2,2.1.1,2.1.2,2.1.3,2.2.1,2.2.2,2.2.3,2.3.1,2.3.2,2.3.3,16.5.1
OWASP DevGuide: SQ3,SQ4,SSV1,SSV2,SSV9,SSV10,LF2
CAPEC™ Map
| Code | Title | ASVS |
|---|---|---|
| 28 | Fuzzing | 1.4.2,2.1.1,2.1.3,2.2.1,2.2.2,2.2.3,2.3.2,2.3.3,16.5.1 |
| 43 | Exploiting Multiple Input Interpretation Layers | 2.1.1,2.1.3,2.2.1,2.2.2,2.3.2,2.3.3,16.5.1 |
| 77 | Manipulating User-Controlled Variables | 2.1.1,2.1.3,2.2.1,2.2.2,2.3.2,2.3.3 |
| 140 | Bypassing of Intermediate Forms in Multiple-Form Sets | 2.2.2,2.2.3,2.3.1,2.3.2,2.3.3 |
| 152 | Inject Unexpected Items | 2.1.1,2.1.2,2.1.3,2.2.1,2.2.2,2.2.3,2.3.2,2.3.3,16.5.1 |
| 153 | Input Data Manipulation | 2.1.1,2.1.2,2.1.3,2.2.1,2.2.2,2.2.3,2.3.2,2.3.3,16.5.1 |
