Improper Validation of Consistency within Input

Incomplete Base
Structure: Simple
Description

This vulnerability occurs when an application accepts structured input containing multiple related fields but fails to verify that the values across those fields are logically consistent with each other.

Extended Description

Many applications process complex data where certain fields must align, like a 'quantity' field followed by a matching number of item entries. If the software doesn't check this internal harmony, attackers can submit deliberately mismatched data. This inconsistency can crash the system, trigger unhandled errors, or cause the application to perform incorrect actions, such as processing the wrong number of items. From a security perspective, failing to validate these relationships opens the door to exploitation. Attackers can use these inconsistencies to bypass business logic, corrupt data in unexpected ways, or uncover deeper flaws that lead to data exposure or system compromise. Consistent validation of all inter-dependent fields is a crucial step in ensuring input integrity and application security.

Common Consequences 1
Scope: Other

Impact: Varies by Context

Potential Mitigations 1
Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Effectiveness: High

Observed Examples 3
CVE-2018-16733product does not validate that the start block appears before the end block
CVE-2006-3790size field that is inconsistent with packet size leads to buffer over-read
CVE-2008-4114system crash with offset value that is inconsistent with packet size
Applicable Platforms
Languages:
Not Language-Specific : Often
Modes of Introduction
Implementation
Related Weaknesses
Notes
MaintenanceThis entry is still under development and will continue to see updates and content improvements.