Data Validation & Encoding (VE9)
Shamun puede eludir la validación de entrada o de salida porque los fallos en las validaciones no son rechazados y/o sanitizados
Unlike other cards in this suit, Data Validation & Encoding 9 (VE9) assumes that input and output validation checks are in place, however they do not correctly respond to incorrect input.
Scenario: Shamun’s Validation Workaround
Imagine a scenario where Shamun, exploiting a critical oversight, bypasses both input and output validation checks in a system. This is possible because the system does not adequately handle validation failures:
- Non-Rejection of Validation Failures: When input or output data fails validation, the system does not outright reject it.
- Lack of Sanitization After Validation Failure: The system fails to sanitize data that doesn't pass validation checks.
Example
Shamun discovers that when certain inputs fail validation checks on your website, instead of rejecting them, the system attempts to process them with minimal or no sanitization. He exploits this by submitting data that is purposefully malformed to fail validation, yet crafted in a way that, when processed, triggers unintended behavior or exposes sensitive information.
Threat Modeling
STRIDE
Shamun is deliberately submitting malformed or invalid data. Because the application does not properly reject it, Shamun’s crafted input is accepted and modifies the system’s behavior or state in unintended ways. Hence Tampering is the most applicable category.
What can go wrong?
This vulnerability can lead to various security threats, including data leakage, unauthorized actions within the system, and the execution of malicious code.
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?
Extensive checks and validations can be made of inputs and outputs, but proper actions following the results is what provides security. Data sanitization is a good approach for outputs, as this data is already accepted by the system. Failing input validation always needs to result in rejection. It is also useful to log (associated with the user's identity if possible) and flag these as probably malicious activity for further analysis, or as input for application intrusion detection systems.
- Implement a strict policy to reject any data that fails validation checks.
- In cases where rejection is not possible, thoroughly sanitize all data post-validation failure.
- Regularly update validation and sanitization procedures to address emerging security threats and ensure comprehensive coverage
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: 16.3.3,16.5.1,16.5.2,16.5.3,16.5.4
OWASP DevGuide: SQ3,SQ4,CEC7,CEC8,COE2,SSV9
CAPEC™ Map
| Code | Title | ASVS |
|---|---|---|
| 24 | Filter Failure through Buffer Overflow | 16.3.3,16.5.1,16.5.2,16.5.3,16.5.4 |
| 28 | Fuzzing | 16.3.3,16.5.1 |
| 152 | Inject Unexpected Items | 16.3.3,16.5.1,16.5.3 |
| 153 | Input Data Manipulation | 16.3.3,16.5.1,16.5.3 |
| 198 | XSS Targeting Error Pages | 16.3.3,16.5.1 |