Only Filtering Special Elements at a Specified Location
This vulnerability occurs when a security filter only checks for dangerous input patterns at specific, predefined locations within the data. It fails to scan the entire input stream, allowing malicious elements that appear outside the expected location to pass through and potentially harm downstream components.
Imagine a filter designed to remove semicolons, but it only checks the very beginning of a user-supplied string. An attacker can simply place the semicolon later in the input—for example, in the middle or at the end—to bypass the filter entirely. This creates a false sense of security because the filter is active, but its limited scope leaves the application exposed to the very attacks it was meant to prevent. This often happens when validation logic uses functions that only look for special characters at absolute positions (like 'byte 10') or relative to markers (like 'the second argument'). Developers must ensure their input sanitization processes perform a comprehensive check across the entire data payload, not just a single, predictable spot. The core failure is a logic error in the filter's design, not the absence of a filter.
Impact: Unexpected State
ID : DX-3
The following code takes untrusted input and uses a regular expression to filter a "../" element located at the beginning of the input string. It then appends this result to the /home/user/ directory and attempts to read the file in the final resulting path.Code Example:
perlCode Example:
bashCode Example:
bashCode Example:
bashID : DX-4
The following code takes untrusted input and uses a substring function to filter a 3-character "../" element located at the 0-index position of the input string. It then appends this result to the /home/user/ directory and attempts to read the file in the final resulting path.Code Example:
perlCode Example:
bashCode Example:
bashCode Example:
bash