Home > CAPEC List > CAPEC-139: Relative Path Traversal (Version 2.11)  

CAPEC-139: Relative Path Traversal

Relative Path Traversal
Definition in a New Window Definition in a New Window
Attack Pattern ID: 139
Abstraction: Detailed
Status: Draft
Completeness: Complete
Presentation Filter:
+ Summary

An attacker exploits a weakness in input validation on the target by supplying a specially constructed path utilizing dot and slash characters for the purpose of obtaining access to arbitrary files or resources. An attacker modifies a known path on the target in order to reach material that is not available through intended channels. These attacks normally involve adding additional path separators (/ or \) and/or dots (.), or encodings thereof, in various combinations in order to reach parent directories or entirely separate trees of the target's directory structure.

+ Attack Steps
  1. Survey application: Using a browser or an automated tool, an attacker follows all public links on a web site. He records all the links he finds. He picks out the URL parameters that may related to access to files.

    Use a spidering tool to follow and record all links. Make special note of any links that include parameters in the URL.

    Use a proxy tool to record all links visited during a manual traversal of the web application. Make special note of any links that include parameters in the URL. Manual traversal of this type is frequently necessary to identify forms that are GET method forms rather than POST forms.

    Use a browser to manually explore the website and analyze how it is constructed. Many browser's plug-in are available to facilitate the analysis or automate the URL discovery.

  1. Attempt variations on input parameters: Possibly using an automated tool, an attacker requests variations on the identified inputs. He sends parameters that include variations of payloads.

    Use a list of probe strings as path traversal payload. Different strings may be used for different platforms. Strings contain relative path sequences such as "../".

    Use a proxy tool to record results of manual input of relative path traversal probes in known URLs.

  1. Access, modify, or execute arbitrary files.: An attacker injects path traversal syntax into identified vulnerable inputs to cause inappropriate reading, writing or execution of files. An attacker could be able to read directories or files which they are normally not allowed to read. The attacker could also access data outside the web document root, or include scripts, source code and other kinds of files from external websites. Once the attacker accesses arbitrary files, he/she could also modify files. In particular situations, the attacker could also execute arbitrary code or system commands.

    Manipulate file and its path by injecting relative path sequences (e.g. "../").

    Download files, modify files, or try to execute shell commands (with binary files).

+ Attack Prerequisites
  • The target application must accept a string as user input, fail to sanitize combinations of characters in the input that have a special meaning in the context of path navigation, and insert the user-supplied string into path navigation commands.

+ Typical Severity


+ Typical Likelihood of Exploit

Likelihood: High

+ Methods of Attack
  • Injection
+ Examples-Instances


The attacker uses relative path traversal to access files in the application. This is an example of accessing user's password file.


However, the target application employs regular expressions to make sure no relative path sequences are being passed through the application to the web page. The application would replace all matches from this regex with the empty string.

Then an attacker creates special payloads to bypass this filter:

http://www.example.com/getProfile.jsp?filename=%2e%2e/%2e%2e/%2e%2e/%2e%2e /etc/passwd

When the application gets this input string, it will be the desired vector by the attacker.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Low

To inject the malicious payload in a web page

Skill or Knowledge Level: High

To bypass non trivial filters in the application

+ Solutions and Mitigations

Design: Input validation. Assume that user inputs are malicious. Utilize strict type, character, and encoding enforcement

Implementation: Perform input validation for all remote content, including remote and user-generated content.

Implementation: Validate user input by only accepting known good. Ensure all content that is delivered to client is sanitized against an acceptable content specification -- whitelisting approach.

Implementation: Prefer working without user input when using file system calls

Implementation: Use indirect references rather than actual file names.

Implementation: Use possible permissions on file access when developing and deploying web applications.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Modify files or directories
Read files or directories
Execute unauthorized code or commands
Run Arbitrary Code
Bypass protection mechanism
DoS: crash / exit / restart
DoS: instability
+ Injection Vector

User-controllable input into web parameters or post variables.

+ Payload

variations on "../../" characters and encoded varieties.

+ Activation Zone

Web server processing of GET or POST content.

+ Payload Activation Impact

• Attackers may create or overwrite critical files.

• Execute unauthorized code or commands.

• Information Leakage of applications that attackers may read confidential files.

• Attackers may delete or corrupt some critical files or data that cause denial of service to legal users.

+ Relevant Security Requirements

Special characters in user-controllable input must be escaped before use by the application. Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application.

+ Purposes
  • Penetration
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Low
+ Technical Context
Architectural Paradigms
+ References
[R.139.1] [REF-5] "The OWASP Application Security Desk Reference". Path Traversal. The Open Web Application Security Project (OWASP). 2009. <https://www.owasp.org/index.php/Path_Traversal>.
[R.139.2] [REF-4] "OWASP Testing Guide". Testing for Path Traversal (OWASP-AZ-001). v3. The Open Web Application Security Project (OWASP). 2010. <https://www.owasp.org/index.php/Testing_for_Path_Traversal_(OWASP-AZ-001)>.
[R.139.3] [REF-1] "WASC Threat Classification 2.0". WASC-33 - Path Traversal. The Web Application Security Consortium (WASC). 2010. <http://projects.webappsec.org/w/page/13246952/Path-Traversal>.
+ Content History
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
CAPEC Content TeamThe MITRE Corporation2015-11-09Updated Attack_PhasesInternal
CAPEC Content TeamThe MITRE Corporation2015-12-07Updated Attack_PhasesInternal
CAPEC Content TeamThe MITRE Corporation2017-01-09Updated Attack_Phases, Related_WeaknessesInternal
CAPEC Content TeamThe MITRE Corporation2017-05-01Updated Attack_PhasesInternal
CAPEC Content TeamThe MITRE Corporation2017-08-04Updated Attack_PhasesInternal

More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2017