Path Traversal

This article details the core principles, practical impacts, and remediation strategies for the Path Traversal (also known as Directory Traversal) vulnerability. This vulnerability arises when an application does not strictly filter the file path parameters provided by users, allowing attackers to use traversal sequences like ../ to bypass the intended directory and read arbitrary sensitive files on the server (such as password files, source code, etc.), and under specific conditions, it can even lead to Remote Code Execution (RCE). The key to defending against this vulnerability is to avoid passing user input directly to file APIs, combined with whitelist input validation and underlying path canonicalization for dual verification.

Type: PortSwigger Required Reading: No

1. 📌 Topic Summary

This document explores the core mechanisms and defense strategies of the Path Traversal (also known as Directory Traversal) vulnerability, and combines 6 practical labs to detail various bypass techniques under different defense mechanisms (such as absolute path blocking, non-recursive filtering, URL decoding, prefix/suffix validation).

2. 🧠 Core Principle

Underlying Mechanism: When a web application directly concatenates user-provided input (such as a filename) into the server’s file path and passes it to the underlying file system operations without strict security verification, it can lead to a Path Traversal vulnerability. Attackers exploit the operating system’s directory parsing rules by inputting special traversal sequences (like ../ in Unix/Linux or ..\ in Windows), causing the parsed path to ‘jump out’ of the application’s intended base directory, thereby accessing the root directory of the file system and other arbitrary files.

Terminology Standards:

• Path Traversal / Directory Traversal - Path Traversal/Directory Traversal vulnerability.
• API - Application Programming Interface. Here refers to the underlying functions provided by the operating system for reading and writing files.
• URL - Uniform Resource Locator.
• PoC - Proof of Concept (concept verification code/payload).
• RCE - Remote Code Execution (AI supplementary note: refers to the attacker exploiting the vulnerability to execute arbitrary system commands on the target server, usually the ultimate impact of file write or inclusion vulnerabilities).

3. 🛠️ Usage & Examples (How to Use)

Application Scenario: Commonly seen in scenarios where resources are dynamically loaded via URL parameters, such as an e-commerce website’s interface for displaying product images: https://insecure-website.com/loadImage?filename=218.png.

Specific Examples & PoC (Combined with Practical Labs): The following summarizes specific payloads for different security defense scenarios, used to read the standard Linux user information file /etc/passwd:

Code/Function Analysis:

• File (Java Class): An abstract representation of file and directory pathnames. For example, new File(BASE_DIRECTORY, userInput) is used to concatenate a base directory with user input.
• getCanonicalPath() (Java Method): Returns the canonical pathname string. This method resolves all relative path symbols like ../ and ./ in the path, as well as symbolic links, ultimately returning the true absolute path of the target file. It is the core function for defense against path traversal.

4. ⚠️ Risk & Impact

If this vulnerability is successfully exploited, it will have extremely severe consequences for the system:

• Sensitive Information Disclosure: Attackers can read application source code, database credentials, and sensitive configuration files of backend systems (such as Linux’s /etc/passwd or Windows’ win.ini).
• Business Data Tampering: If the application has not only read vulnerabilities but also file write vulnerabilities, attackers can modify application data or system configuration files.
• Complete System Takeover: (AI supplementary note) Attackers can achieve RCE (Remote Code Execution) and fully control the server by writing SSH keys, overwriting Cron jobs, or uploading WebShells.

5. 🛡️ Defense & Mitigation

The most effective defense strategy is to completely avoid passing user-provided input directly to the underlying file system API. If business logic makes it unavoidable, the following two-layer defense mechanism must be adopted:

1. Strict Input Validation：
   • Best Practice: Use a whitelist mechanism to allow only pre-defined safe filenames.
   • Alternative: If a whitelist cannot be used, the input must be validated via regular expressions to ensure it contains only allowed characters (e.g., alphanumeric characters only), and any input containing /, \, or %00 must be completely rejected.
2. Path Canonicalization and Base Directory Verification：
   • Do not write your own logic to filter ../ (it can be easily bypassed by the techniques in the above Lab).
   • Use the standard file system API provided by the platform to ‘canonicalize’ the path (resolve all traversal symbols), then verify that the canonicalized absolute path still starts with the expected base directory.
   • Java Fix Example：

// 1. Concatenate user input with base directory
File file = new File(BASE_DIRECTORY, userInput);
// 2. Obtain the canonical absolute path and verify that it hasn't escaped the secure directory
if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) {
    // process file (safe, can process the file)
} else {
    // reject the request, log security event
}

3. Principle of Least Privilege (AI Supplementary Note)：

• Ensure that the service account running the web application (e.g., www-data) has only read access to necessary directories (e.g., /var/www/images/), and strictly prohibit granting access to system-level directories (e.g., /etc/).