Relative Path Traversal| ID: 23 | Date: (C)2012-05-14 (M)2022-10-10 | | Type: weakness | Status: DRAFT | | Abstraction Type: Base |
Description The software uses external input to construct a pathname that
should be within a restricted directory, but it does not properly neutralize
sequences such as ".." that can resolve to a location that is outside of that
directory. Extended DescriptionThis allows attackers to traverse the file system to access files or
directories that are outside of the restricted directory. Applicable PlatformsLanguage Class: All Time Of Introduction Related Attack Patterns Common Consequences | Scope | Technical Impact | Notes |
|---|
| IntegrityConfidentialityAvailability | Execute unauthorized code or
commands | The attacker may be able to create or overwrite critical files that
are used to execute code, such as programs or libraries. | | Integrity | Modify files or
directories | The attacker may be able to overwrite or create critical files, such
as programs, libraries, or important data. If the targeted file is used
for a security mechanism, then 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 /
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 software 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 software. |
Detection MethodsNone Potential Mitigations | Phase | Strategy | Description | Effectiveness | Notes |
|---|
| Implementation | Input Validation | Assume all input is malicious. Use an "accept known good" input
validation strategy, i.e., use a whitelist 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
(i.e., do not rely on a blacklist). A blacklist 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, blacklists 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 whitelists 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 whitelist 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 blacklist,
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. | | | | Implementation | 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 whitelist 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: | | |
Relationships | Related CWE | Type | View | Chain |
|---|
| CWE-23 ChildOf CWE-893 | Category | CWE-888 | |
Demonstrative Examples (Details) - The following URLs are vulnerable to this attack:
- 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. (Demonstrative Example Id DX-27)
- The following code demonstrates the unrestricted upload of a file
with a Java servlet and a path traversal vulnerability. The action attribute
of an HTML form is sending the upload file request to the Java
servlet. (Demonstrative Example Id DX-22)
Observed Examples - CVE-2002-0298 : Server allows remote attackers to cause a denial of service via certain HTTP GET requests containing a %2e%2e (encoded dot-dot), several "/../" sequences, or several "../" in a URI.
- CVE-2002-0661 : "\" not in blacklist for web server, allowing path traversal attacks when the server is run in Windows and other OSes.
- CVE-2002-0946 : Arbitrary files may be read files via ..\ (dot dot) sequences in an HTTP request.
- CVE-2002-1042 : Directory traversal vulnerability in search engine for web server allows remote attackers to read arbitrary files via "..\" sequences in queries.
- CVE-2002-1209 : Directory traversal vulnerability in FTP server allows remote attackers to read arbitrary files via "..\" sequences in a GET request.
- CVE-2002-1178 : Directory traversal vulnerability in servlet allows remote attackers to execute arbitrary commands via "..\" sequences in an HTTP request.
- CVE-2002-1987 : Protection mechanism checks for "/.." but doesn't account for Windows-specific "\.." allowing read of arbitrary files.
- CVE-2005-2142 : Directory traversal vulnerability in FTP server allows remote authenticated attackers to list arbitrary directories via a "\.." sequence in an LS command.
- CVE-2002-0160 : The administration function in Access Control Server allows remote attackers to read HTML, Java class, and image files outside the web root via a "..\.." sequence in the URL to port 2002.
- CVE-2001-0467 : "\..." in web server
- CVE-2001-0963 : "..." in cd command in FTP server
- CVE-2001-1193 : "..." in cd command in FTP server
- CVE-2001-1131 : "..." in cd command in FTP server
- CVE-2001-0480 : read of arbitrary files and directories using GET or CD with "..." in Windows-based FTP server.
- CVE-2002-0288 : read files using "." and Unicode-encoded "/" or "\" characters in the URL.
- CVE-2003-0313 : Directory listing of web server using "..."
- CVE-2005-1658 : Triple dot
- CVE-2000-0240 : read files via "/........../" in URL
- CVE-2000-0773 : read files via "...." in web server
- CVE-1999-1082 : read files via "......" in web server (doubled triple dot?)
- CVE-2004-2121 : read files via "......" in web server (doubled triple dot?)
- CVE-2001-0491 : multiple attacks using "..", "...", and "...." in different commands
- CVE-2001-0615 : "..." or "...." in chat server
- CVE-2005-2169 : chain: ".../...//" bypasses protection mechanism using regexp's that remove "../" resulting in collapse into an unsafe value "../" (CWE-182) and resultant path traversal.
- CVE-2005-0202 : ".../....///" bypasses regexp's that remove "./" and "../"
- CVE-2004-1670 : Mail server allows remote attackers to create arbitrary directories via a ".." or rename arbitrary files via a "....//" in user supplied parameters.
For more examples, refer to CVE relations in the bottom box. White Box Definitions None Black Box Definitions None Taxynomy Mappings | Taxynomy | Id | Name | Fit |
|---|
| PLOVER | | Relative Path Traversal | |
References: - OWASP .OWASP Attack listing.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 9, "Filenames and Paths", Page
503.'. Published on 2006.
|
