227
The product receives input from an upstream component, but it does not neutralize or incorrectly
neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
Extended Description
This may allow an attacker to execute arbitrary code, or at least modify what code can be
executed.
Relationships
The table(s) below shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOr and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition, relationships such
as PeerOf and CanAlsoBe are defined to show similar weaknesses that may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name Page
ChildOf 94 Improper Control of Generation of Code ('Code Injection') 219
Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name Page
MemberOf 1019 Validate Inputs 2433
Weakness Ordinalities
Primary :
Applicable Platforms
Language : Java (Prevalence = Undetermined)
Language : JavaScript (Prevalence = Undetermined)
Language : Python (Prevalence = Undetermined)
Language : Perl (Prevalence = Undetermined)
Language : PHP (Prevalence = Undetermined)
Language : Ruby (Prevalence = Undetermined)
Language : Interpreted (Prevalence = Undetermined)
Likelihood Of Exploit
Medium
Common Consequences
Scope Impact Likelihood
Confidentiality Read Files or Directories
Read Application Data
The injected code could access restricted data / files.
Access Control Bypass Protection Mechanism
In some cases, injectable code controls authentication; this
may lead to a remote vulnerability.
Access Control Gain Privileges or Assume Identity
Injected code can access resources that the attacker is
directly prevented from accessing.
Integrity
Confidentiality
Availability
Other
Execute Unauthorized Code or Commands
Code injection attacks can lead to loss of data integrity
in nearly all cases as the control-plane data injected is
always incidental to data recall or writing. Additionally,
CWE Version 4.14
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
CWE-95: Improper Neutralization of Directives
in Dynamically Evaluated Code ('Eval Injection') 228
Scope Impact Likelihood
code injection can often result in the execution of arbitrary
code.
Non-Repudiation Hide Activities
Often the actions performed by injected control code are
unlogged.
Detection Methods
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST),
can find some instances of this weakness by analyzing source code (or binary/compiled code)
without having to execute it. Typically, this is done by building a model of data flow and control
flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input)
with "sinks" (destinations where the data interacts with external components, a lower layer such
as the OS, etc.)
Effectiveness = High
Potential Mitigations
Phase: Architecture and Design
Phase: Implementation
If possible, refactor your code so that it does not need to use eval() at all.
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
Inputs should be decoded and canonicalized to the application's current internal representation
before being validated (CWE-180, CWE-181). Make sure that your application does not
inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass
allowlist schemes by introducing dangerous inputs after they have been checked. Use
libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated
canonicalization until your input does not change any more. This will avoid double-decoding and
similar scenarios, but it might inadvertently modify inputs that are allowed to contain properlyencoded
dangerous content.
Phase: Implementation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of
eval, since it is intentionally designed to avoid executing code. However, an adversary could still
cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the
python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
Effectiveness = Discouraged Common Practice
CWE Version 4.14
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
CWE-95: Improper Neutralization of Directives
in Dynamically Evaluated Code ('Eval Injection')