Home > CAPEC List > CAPEC-126: Path Traversal (Version 2.10)  

CAPEC-126: Path Traversal

 
Path Traversal
Definition in a New Window Definition in a New Window
Attack Pattern ID: 126
Abstraction: Standard
Status: Draft
Completeness: Stub
Presentation Filter:
+ Summary

An adversary uses path manipulation methods to exploit insufficient input validation of a target to obtain access to data that should be not be retrievable by ordinary well-formed requests. A typical variety of this attack involves specifying a path to a desired file together with dot-dot-slash characters, resulting in the file access API or function traversing out of the intended directory structure and into the root file system. By replacing or modifying the expected path information the access function or API retrieves the file desired by the attacker. These attacks either involve the attacker providing a complete path to a targeted file or using control characters (e.g. path separators (/ or \) and/or dots (.)) to reach desired directories or files.

+ Alternate Terms

Term: Directory Traversal

+ Attack Prerequisites
  • The attacker must be able to control the path that is requested of the target.

  • The target must fail to adequately sanitize incoming paths

+ Typical Severity

Very High

+ Typical Likelihood of Exploit

Likelihood: High

+ Examples-Instances

Description

An example of using path traversal to attack some set of resources on a web server is to use a standard HTTP request

http://example/../../../../../etc/passwd

From an attacker point of view, this may be sufficient to gain access to the password file on a poorly protected system. If the attacker can list directories of critical resources then read only access is not sufficient to protect the system.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Low

Simple command line attacks or to inject the malicious payload in a web page.

Skill or Knowledge Level: Medium

Customizing attacks to bypass non trivial filters in the application.

+ Resources Required

The ability to manually manipulate path information either directly through a client application relative to the service or application or via a proxy application.

+ Solutions and Mitigations

Design: Configure the access control correctly.

Design: Enforce principle of least privilege.

Design: Execute programs with constrained privileges, so parent process does not open up further vulnerabilities. Ensure that all directories, temporary directories and files, and memory are executing with limited privileges to protect against remote execution.

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

Design: Proxy communication to host, so that communications are terminated at the proxy, sanitizing the requests before forwarding to server host.

Design: Run server interfaces with a non-root account and/or utilize chroot jails or other configuration techniques to constrain privileges even if attacker gains some limited access to commands.

Implementation: Host integrity monitoring for critical files, directories, and processes. The goal of host integrity monitoring is to be aware when a security issue has occurred so that incident response and other forensic activities can begin.

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

Implementation: Perform testing such as pen-testing and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables.

Implementation: Use indirect references rather than actual file names.

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

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.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Integrity
Confidentiality
Availability
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.
+ Injection Vector

Payload delivered through standard communication protocols and inputs.

+ Payload

File system commands and specifiers

+ Activation Zone

File system

+ Payload Activation Impact

File access or modification.

+ 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
Client-Server
n-Tier
Frameworks
All
Platforms
All
Languages
All
+ References
[R.76.1] [REF-2] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. February 2004.
[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
Submissions
SubmitterOrganizationDateSource
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
Modifications
ModifierOrganizationDateCommentsSource
CAPEC Content TeamThe MITRE Corporation2017-01-09Updated Activation_Zone, Alternate_Terms, Architectural_Paradigms, Attack_Motivation-Consequences, Attacker_Skills_or_Knowledge_Required, CIA_Impact, Examples-Instances, Frameworks, Injection_Vector, Languages, Payload, Payload_Activation_Impact, Platforms, Purposes, References, Related_Attack_Patterns, Related_Vulnerabilities, Related_Weaknesses, Relevant_Security_Requirements, Solutions_and_Mitigations, Technical_Context, Typical_Likelihood_of_Exploit, Typical_SeverityInternal
More information is available — Please select a different filter.
Page Last Updated or Reviewed: May 01, 2017