Path Traversal

This article provides a detailed analysis of the core principles, actual threats, and mitigation strategies for path traversal (also known as directory traversal) vulnerabilities. The vulnerability arises from the lack of strict security filtering on file path parameters provided by users, allowing attackers to exploit jump sequences such as ../ to bypass predefined directories and read any sensitive files on the server (e.g., password files, source code, etc.). Under certain conditions, it can even lead to remote code execution (RCE). The key to defending against this vulnerability lies in avoiding direct transmission of user input to file APIs, and implementing a dual-check mechanism that includes whitelist validation and underlying path normalization.

Type: PortSwigger Recommended Reading: None

1. 📌 Topic Summary

This document explores the mechanisms behind path traversal (also known as directory traversal) vulnerabilities and outlines defense strategies. It includes six practical experiments (Labs) that demonstrate various bypass techniques under different defense mechanisms, such as absolute path interception, non-recursive filtering, URL decoding, and prefix/suffix validation.

2. 🧠 Core Principle

Underlying Mechanism: When a web application directly appends user-provided input (e.g., file names) to the server’s file path and passes it to the underlying file system operations without strict security verification, a path traversal vulnerability is created. Attackers exploit the directory resolution rules of the operating system by inserting special traversal sequences (e.g., ../ on Unix/Linux or ..\ on Windows). This causes the parsed path to “jump out” of the base directory defined by the application, allowing access to the file system root directory and files in any other location.

Terminology Explanation:

• Path Traversal / Directory Traversal: A vulnerability that allows an attacker to access files outside the intended scope.
• API: Application Programming Interface, referring to the underlying functions provided by the operating system for file I/O.
• URL: Uniform Resource Locator.
• PoC (Proof of Concept): Code or payload used to demonstrate a vulnerability.
• RCE (Remote Code Execution): An attacker uses the vulnerability to execute arbitrary system commands on the target server, typically leading to file manipulation or the execution of malicious code.

3. 🛠️ Practical Applications and Examples (How to Use)

Use Cases: This vulnerability is 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 and PoCs (Combined with Practical Labs): The following examples demonstrate different types of attack payloads used to read the standard Linux user information file /etc/passwd in various security defense scenarios:

Code/Function Explanation:

• File (Java Class): Represents an abstract representation of file and directory paths. For example, new File(BASE_DIRECTORY, userInput) is used to concatenate the base directory with user input.
• getCanonicalPath() (Java Method): Returns the canonical pathname string: This method parses all relative path symbols (such as ../ and ./) and symbolic links in the path, ultimately returning the actual absolute path of the target file. It is a key function for defending against path traversal attacks.

4. ⚠️ Risk and Impact**

If this vulnerability is successfully exploited, it can have extremely serious consequences for the system:

• Sensitive Information Leakage: Attackers can access application source code, database credentials, and sensitive configuration files from the backend system (e.g., /etc/passwd on Linux or win.ini on Windows).
• Business Data Tampering: If the application also has a write vulnerability, attackers can modify application data or system configuration files.
• Full System Control: (Additional AI Explanation) Attackers can achieve Remote Code Execution (RCE) by writing SSH keys, overwriting scheduled tasks (Cron jobs), or uploading a WebShell, ultimately taking complete control of the server.

5. 🛡️ Defense and Mitigation Recommendations

The most effective defense strategy is to thoroughly avoid passing user-provided input directly to the underlying file system APIs. If business logic makes this unavoidable, the following dual-layer defense mechanism must be implemented:

1. Strict Input Validation:
   • Best Practice: Use a whitelist to only allow predefined, safe filenames.
   • Alternative: If a whitelist cannot be used, validate the input using regular expressions to ensure it contains only allowed characters (e.g., only alphanumeric characters), and explicitly reject any input that contains /, \, or %00.
2. Path Canonicalization and Base Directory Verification:
   • Do not attempt to manually filter ../ paths (as this can be easily bypassed by the techniques used in the lab).
   • Use the standard file system APIs provided by the platform to canonicalize the paths (remove all traversal symbols), and then verify whether the normalized absolute path still starts with the expected base directory.
   • Example of Java code for mitigation:

// 1. Concatenate the user input with the base directory
File file = new File(BASE_DIRECTORY, userInput);
// 2. Get the normalized absolute path and verify if it does not exceed the safe directory limits
if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) {
    // Process the file (it is safe to do so)
} else {
    // Reject the request and log it as a security incident
}

1. Principle of Least Privilege (Additional explanation by AI):

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