1744
only limits the impact to the operating system; the rest of the application may still be subject to
compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness = Limited
The effectiveness of this mitigation depends on the prevention capabilities of the specific
sandbox or jail being used and might only help to reduce the scope of an attack, such as
restricting the attacker to certain system calls or limiting the portion of the file system that can be
accessed.
Phase: Architecture and Design
Phase: Operation
Strategy = Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks
[REF-76]. If possible, create isolated accounts with limited privileges that are only used for a
single task. That way, a successful attack will not immediately give the attacker access to the
rest of the software or its environment. For example, database applications rarely need to run as
the database administrator, especially in day-to-day operations.
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. When validating
filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a
single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory
separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help
to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially
dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For
example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a
directory separator. Another possible error could occur when the filtering is applied in a way that
still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the
".../...//" string in a sequential fashion, two instances of "../" would be removed from the original
string, but the remaining characters would still form the "../" string.
Effectiveness = High
Phase: Architecture and Design
Phase: Operation
Strategy = Attack Surface Reduction
Store library, include, and utility files outside of the web document root, if possible. Otherwise,
store them in a separate directory and use the web server's access control capabilities to prevent
attackers from directly requesting them. One common practice is to define a fixed constant in
each calling program, then check for the existence of the constant in the library/include file; if the
constant does not exist, then the file was directly requested, and it can exit immediately. This
CWE Version 4.14
CWE-829: Inclusion of Functionality from Untrusted Control Sphere
CWE-829: Inclusion of Functionality from Untrusted Control Sphere