37
Phase: Implementation
Strategy = Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation
before being validated (CWE-180). Make sure that the application does not decode the same
input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by
introducing dangerous inputs after they have been checked. Use a built-in path canonicalization
function (such as realpath() in C) that produces the canonical version of the pathname, which
effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
realpath() in C getCanonicalPath() in Java GetFullPath() in ASP.NET realpath() or abs_path() in
Perl realpath() in PHP
Phase: Architecture and Design
Strategy = Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides
constructs that make this weakness easier to avoid.
Phase: Operation
Strategy = Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial
in cases in which the code cannot be fixed (because it is controlled by a third party), as an
emergency prevention measure while more comprehensive software assurance measures are
applied, or to provide defense in depth.
Effectiveness = Moderate
An application firewall might not cover all possible input vectors. In addition, attack techniques
might be available to bypass the protection mechanism, such as using malformed inputs that can
still be processed by the component that receives those inputs. Depending on functionality, an
application firewall might inadvertently reject or modify legitimate requests. Finally, some manual
effort may be required for customization.
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: Architecture and Design
Strategy = Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a
mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs,
and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to
"profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.
Phase: Architecture and Design
Phase: Operation
Strategy = Sandbox or Jail
Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between
the process and the operating system. This may effectively restrict which files can be accessed
in a particular directory or which commands can be executed by the software. OS-level examples
CWE Version 4.14
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CWE-22: Improper Limitation of a Pathname
to a Restricted Directory ('Path Traversal') 38
include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide
some protection. For example, java.io.FilePermission in the Java SecurityManager allows the
software to specify restrictions on file operations. This may not be a feasible solution, and it
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 = 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
significantly reduces the chance of an attacker being able to bypass any protection mechanisms
that are in the base program but not in the include files. It will also reduce the attack surface.
Phase: Implementation
Ensure that error messages only contain minimal details that are useful to the intended audience
and no one else. The messages need to strike the balance between being too cryptic (which
can confuse users) or being too detailed (which may reveal more than intended). The messages
should not reveal the methods that were used to determine the error. Attackers can use detailed
information to refine or optimize their original attack, thereby increasing their chances of success.
If errors must be captured in some detail, record them in log messages, but consider what
could occur if the log messages can be viewed by attackers. Highly sensitive information such
as passwords should never be saved to log files. Avoid inconsistent messaging that might
accidentally tip off an attacker about internal state, such as whether a user account exists or
not. In the context of path traversal, error messages which disclose path information can help
attackers craft the appropriate attack strings to move through the file system hierarchy.
Phase: Operation
Phase: Implementation
Strategy = Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During
implementation, develop the application so that it does not rely on this feature, but be wary of
implementing a register_globals emulation that is subject to weaknesses such as CWE-95,
CWE-621, and similar issues.
Demonstrative Examples
Example 1:
The following code could be for a social networking application in which each user's profile
information is stored in a separate file. All files are stored in a single directory.
Example Language: Perl (Bad)
my $dataPath = "/users/cwe/profiles";
my $username = param("user");
my $profilePath = $dataPath . "/" . $username;
open(my $fh, "<", $profilePath) || ExitError("profile read error: $profilePath");
CWE Version 4.14
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CWE-22: Improper Limitation of a Pathname
to a Restricted Directory ('Path Traversal')