Data Validation & Encoding (VE3)

This card relates to generic input validation. See Data Validation & Sanitization 4 for the similar additional context-specific checks.

Scenario: Robert’s Clever Exploits

Imagine a scenario where Robert, an astute attacker, manipulates your system by inputting malicious data. He takes advantage of the system's failure in several critical areas:

1. Unchecked Protocol Formats: The system doesn't verify if the data conforms to the expected protocol format.
2. Acceptance of Duplicates: The system allows duplicate data entries, which it should normally reject.
3. Unverified Structure: There's no check to ensure the overall structure of the data is consistent.
4. Inadequate Data Element Validation: The system fails to validate individual data elements for format, type, range, length, or against a whitelist of allowed characters or formats.

Example

Robert attacks by submitting a form on your website. He intentionally uses an unexpected data format, like entering alphabetic characters where only numbers are expected. The system, not checking the format or range, accepts this input, leading to potential processing errors or more severe security vulnerabilities, such as injection attacks.

Threat Modeling

STRIDE

The primary STRIDE category for “being able to input malicious data due to missing protocol/structure/element validation” is Tampering with possible secondary impacts into Information Disclosure, DoS, or Elevation of Privilege depending on how the malformed data is exploited.

What can go wrong?

These oversights can result in significant security breaches, data corruption, and may compromise the integrity and reliability of the entire system.

A lack of input validation is often the root cause of many security issues. Since the validation needs to be context specific, generic sanitisation routines will not suffice.

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?

The developer needs to understand how data are formatted/composed, why the data is being sent, what it is used for and the meaning of the values.

1. Rigorously validate all data inputs, fields and parameters for their format, type, range, length, and against a comprehensive whitelist.
2. Regularly update and refine these validation rules to stay ahead of sophisticated attack techniques.
3. Only the permitted inputs (field/parameter names) must be allowed.
4. All the mandatory inputs must be enforced.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.