394
ParentOf 151 Improper Neutralization of Comment Delimiters 396
ParentOf 152 Improper Neutralization of Macro Symbols 398
ParentOf 153 Improper Neutralization of Substitution Characters 400
ParentOf 154 Improper Neutralization of Variable Name Delimiters 401
ParentOf 155 Improper Neutralization of Wildcards or Matching Symbols 403
ParentOf 156 Improper Neutralization of Whitespace 405
ParentOf 157 Failure to Sanitize Paired Delimiters 407
ParentOf 158 Improper Neutralization of Null Byte or NUL Character 409
ParentOf 159 Improper Handling of Invalid Use of Special Elements 411
ParentOf 160 Improper Neutralization of Leading Special Elements 413
ParentOf 162 Improper Neutralization of Trailing Special Elements 417
ParentOf 164 Improper Neutralization of Internal Special Elements 420
ParentOf 464 Addition of Data Structure Sentinel 1107
ParentOf 790 Improper Filtering of Special Elements 1678
Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name Page
MemberOf 1019 Validate Inputs 2433
Weakness Ordinalities
Primary :
Applicable Platforms
Language : Not Language-Specific (Prevalence = Undetermined)
Common Consequences
Scope Impact Likelihood
Confidentiality
Integrity
Availability
Other
Execute Unauthorized Code or Commands
Alter Execution Logic
DoS: Crash, Exit, or Restart
Potential Mitigations
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
CWE Version 4.14
CWE-138: Improper Neutralization of Special Elements
CWE-138: Improper Neutralization of Special Elements