Improper Neutralization of Special Elements

Description

This vulnerability occurs when an application accepts external input but fails to properly sanitize special characters or syntax that have specific meanings in the target interpreter or protocol. This allows attackers to inject control elements that alter how downstream components process the data.

Extended Description

Programming languages, command shells, databases, and network protocols all use special characters and reserved words as syntactic markers—like quotes, angle brackets, or escape sequences—to define commands or structure data. When an application passes unsanitized user input containing these elements to an interpreter, the interpreter may execute unintended actions, such as reading a file, terminating a command, or altering a query. For example, the `<` character is interpreted by many shells as a directive to read input from a file, while SQL uses the single quote (`'`) to delimit strings. Without proper neutralization (often called sanitization or escaping), an attacker can break out of the intended data context and inject malicious instructions, leading to data breaches, system compromise, or unexpected application behavior.

Common Consequences 1

Scope: ConfidentialityIntegrityAvailabilityOther

Impact: Execute Unauthorized Code or CommandsAlter Execution LogicDoS: Crash, Exit, or Restart

Potential Mitigations 5

Phase: Implementation

Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their product. One defense is to create an allowlist (e.g. a regular expression) that defines valid input according to the requirements specifications. Strictly filter any input that does not match against the allowlist. Properly encode your output, and quote any elements that have special meaning to the component with which you are communicating.

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.

Phase: Implementation

Use and specify an appropriate output encoding to ensure that the special elements are well-defined. A normal byte sequence in one encoding could be a special element in another.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (Incorrect Behavior Order: Validate Before Canonicalize). Make sure that the application does not decode the same input twice (Double Decoding of the Same Data). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

Phase: Implementation

Strategy: Output Encoding

While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')).

Observed Examples 4

CVE-2001-0677Read arbitrary files from mail client by providing a special MIME header that is internally used to store pathnames for attachments.

CVE-2000-0703Setuid program does not cleanse special escape sequence before sending data to a mail program, causing the mail program to process those sequences.

CVE-2003-0020Multi-channel issue. Terminal escape sequences not filtered from log files.

CVE-2003-0083Multi-channel issue. Terminal escape sequences not filtered from log files.

Applicable Platforms

Languages:

Not Language-Specific : Undetermined

Modes of Introduction

Implementation

Related Attack Patterns

Related Weaknesses

ChildOf:

Improper Neutralization (CWE-707)

Taxonomy Mapping

PLOVER
PLOVER
Software Fault Patterns

Notes

RelationshipThis weakness can be related to interpretation conflicts or interaction errors in intermediaries (such as proxies or application firewalls) when the intermediary's model of an endpoint does not account for protocol-specific special elements.

RelationshipSee this entry's children for different types of special elements that have been observed at one point or another. However, it can be difficult to find suitable CVE examples. In an attempt to be complete, CWE includes some types that do not have any associated observed example.

Research GapThis weakness is probably under-studied for proprietary or custom formats. It is likely that these issues are fairly common in applications that use their own custom format for configuration files, logs, meta-data, messaging, etc. They would only be found by accident or with a focused effort based on an understanding of the format.