Data Validation & Encoding (VE7)

Without strict character-set enforcement, canonicalization, and strong typing, attackers can craft ambiguously encoded payloads that evade input validation and tamper with the application.

Scenario: Jan's Crafty Payloads

Envision a situation where Jan, an astute intruder, manages to craft special payloads that circumvent input validation measures. He exploits several key weaknesses in the system:

1. Unspecified/Unenforced Character Set: The system fails to define or enforce a consistent character set for inputs.
2. Multiple Encodings: Data is encoded more than once, creating complexities that obscure malicious content.
3. Inadequate Data Conversion (Canonicalization): Data isn't fully converted into the format the application uses before being validated.
4. Weak Typing of Variables: Variables in the system are not strongly typed, allowing for type mismatches that can be exploited.

Example

Jan targets the system by submitting a payload with characters that change meaning based on the character set. For instance, he uses a character set where certain symbols are interpreted differently, bypassing filters that would otherwise block malicious inputs. Due to the system not strictly enforcing a character set, or fully converting data into a consistent format, his payload is processed without proper validation, leading to potential security breaches.

Threat Modeling

STRIDE

This scenario falls into the Tampering category of STRIDE. Crafting special/ambiguously encoded payloads to foil validation is an attack on the integrity of input data (i.e., tampering). Jan is modifying the data semantics (by using alternate encodings, double-encoding, differing charset interpretations, etc.) so that filters/validators no longer recognize the malicious content. STRIDE’s Tampering covers unauthorized modification or manipulation of data or how data is interpreted, which is exactly what character-set/canonicalization tricks do.

What can go wrong?

These vulnerabilities can result in severe security issues, such as injection attacks, data corruption, and unauthorized system access.

Without knowing the character encoding accurately, data validation routines could be inadequate. A web application firewall, a web server, an application server, a database server, and other interpreters could each be susceptible, and susceptible in different ways, to malicious character encoding issues.

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?

1. Use system components that support UTF-8 extended character sets. Specify proper character sets, such as UTF-8, for all sources of input.
2. Prevent complications from multiple encodings by standardizing the encoding process.
3. Ensure complete data conversion into the application’s format (canonicalization) before validation.
4. Use strong typing for variables to prevent type-related security loopholes.

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