35
Scope Impact Likelihood
the attacker may be able to bypass that mechanism.
For example, appending a new account at the end
of a password file may allow an attacker to bypass
authentication.
Confidentiality Read Files or Directories
The attacker may be able read the contents of unexpected
files and expose sensitive data. If the targeted file is used
for a security mechanism, then the attacker may be able
to bypass that mechanism. For example, by reading a
password file, the attacker could conduct brute force
password guessing attacks in order to break into an
account on the system.
Availability DoS: Crash, Exit, or Restart
The attacker may be able to overwrite, delete, or corrupt
unexpected critical files such as programs, libraries, or
important data. This may prevent the product from working
at all and in the case of a protection mechanisms such as
authentication, it has the potential to lockout every user of
the product.
Detection Methods
Automated Static Analysis
Automated techniques can find areas where path traversal weaknesses exist. However, tuning
or customization may be required to remove or de-prioritize path-traversal problems that are only
exploitable by the product's administrator - or other privileged users - and thus potentially valid
behavior or, at worst, a bug instead of a vulnerability.
Effectiveness = High
Manual Static Analysis
Manual white box techniques may be able to provide sufficient code coverage and reduction of
false positives if all file access operations can be assessed within limited time constraints.
Effectiveness = High
Automated Static Analysis - Binary or Bytecode
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Bytecode Weakness Analysis - including disassembler + source code weakness analysis Cost
effective for partial coverage: Binary Weakness Analysis - including disassembler + source code
weakness analysis
Effectiveness = High
Manual Static Analysis - Binary or Bytecode
According to SOAR, the following detection techniques may be useful: Cost effective for partial
coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities &
anomalies
Effectiveness = SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR, the following detection techniques may be useful: Highly cost effective: Web
Application Scanner Web Services Scanner Database Scanners
Effectiveness = High
Dynamic Analysis with Manual Results Interpretation
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') 36
According to SOAR, the following detection techniques may be useful: Highly cost effective: Fuzz
Tester Framework-based Fuzzer
Effectiveness = High
Manual Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused
Manual Spotcheck - Focused manual analysis of source
Effectiveness = High
Automated Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
Effectiveness = High
Architecture or Design Review
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE
1028 standard) (can apply to requirements, design, source code, etc.)
Effectiveness = High
Potential Mitigations
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.
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are
duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side
checks by modifying values after the checks have been performed, or by changing the client to
remove the client-side checks entirely. Then, these modified values would be submitted to the
server.
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')