221
Common Consequences
Scope Impact Likelihood
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
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,
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
Refactor your program so that you do not have to dynamically generate code.
Phase: Architecture and Design
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between
the process and the operating system. This may effectively restrict which code can be executed
by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code
may provide some protection. This may not be a feasible solution, and it only limits the impact to
the operating system; the rest of your application may still be subject to compromise. Be careful
to avoid CWE-243 and other weaknesses related to jails.
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
CWE Version 4.14
CWE-94: Improper Control of Generation of Code ('Code Injection')
CWE-94: Improper Control of Generation of Code ('Code Injection')