Manual Testing for Relative Path Traversal Vulnerabilities: A Deep Dive

Welcome to another installment of the Learn Pentesting series from Numorian. In this post, we will dive deep into the manual testing techniques for detecting relative path traversal vulnerabilities in web applications. This guide is intended for penetration testers and security professionals who want to add rigorous manual testing techniques to their toolkit.

Overview

Relative Path Traversal (RPT) is a class of vulnerabilities that occur when a web application fails to properly sanitize user-supplied input used in file paths. This can allow attackers to navigate the file system and access sensitive files such as configuration files, password files, or even system logs. In this post, we will cover:

What relative path traversal is and why it matters
Manual testing techniques for identifying these vulnerabilities
Code examples and payloads to use during testing
Tips for interpreting the results

Understanding Relative Path Traversal

Relative path traversal vulnerabilities allow an attacker to manipulate file path references by injecting special characters—most commonly ../ (dot-dot-slash)—to traverse directories. Here’s a brief technical overview:

Normal File Access: A web application might retrieve files based on user input, for example, file.php?doc=about.html. The application might simply append the input to a directory path.
Vulnerable Scenario: If the input is not sanitized, an attacker can supply ../ sequences to move up the directory tree. For example, file.php?doc=../../../../etc/passwd may cause the application to read the sensitive /etc/passwd file on Unix systems.
Variations and Bypasses: Attackers often use encoding or alternative representations to bypass simple input filters. Techniques include URL encoding (e.g., %2e%2e/), double encoding, or using alternate separators (e.g., backslashes on Windows).

Understanding these fundamentals is essential before moving on to hands-on testing.

Setting Up a Testing Environment

Before testing any application for vulnerabilities, ensure that you have proper authorization. For practice, consider using a controlled environment or intentionally vulnerable applications like DVWA (Damn Vulnerable Web Application) or bWAPP.

Environment Checklist:

Web Server: A web application that accepts file path inputs.
Authorization: Explicit permission to perform penetration tests on the application.
Testing Tools: A modern web browser, a proxy tool (e.g., Burp Suite), and a scripting language (e.g., Python with the requests library).

Manual Testing Techniques

Step 1: Identify Input Vectors

Start by analyzing the application to find parameters that accept file names or paths. Look for URL parameters (e.g., ?file=, ?doc=) or form inputs that reference file paths.

Step 2: Inject Traversal Sequences

Once you’ve identified potential vectors, manually inject traversal payloads into the parameter. Common payloads include:

../etc/passwd
..%2Fetc%2Fpasswd
%2E%2E/%2E%2E/etc/passwd
....//....//etc/passwd (attempting to bypass simple filters)
For Windows targets: ..\..\windows\win.ini

Step 3: Observe the Response

After injecting each payload, observe the server’s response:

Success Indicators: The appearance of system-specific content (e.g., lines starting with root: from /etc/passwd or configuration settings from win.ini).
Error Messages: Sometimes, error messages (e.g., “File not found” or “Access denied”) can provide clues about the file structure.

Step 4: Utilize a Proxy Tool

Using a proxy tool like Burp Suite allows you to modify requests on the fly and inspect responses in detail. This is particularly useful for:

Tracking redirections or error messages.
Replaying requests with minor variations in payload encoding.
Capturing response headers that might indicate the file type or path.

Code Example: Automated Testing for Path Traversal

Below is a Python script that demonstrates how to automate the testing process for relative path traversal vulnerabilities. This script uses the requests library to iterate over a set of payloads and check the responses for signs of vulnerability.

import requests

# Base URL with a vulnerable parameter (modify as needed)
base_url = "http://target-website.com/vulnerable.php?file="

# List of payloads for testing traversal vulnerabilities
payloads = [
    "../etc/passwd",
    "..%2Fetc%2Fpasswd",
    "%2E%2E/%2E%2E/etc/passwd",
    "....//....//etc/passwd",
    "../windows/win.ini",          # For Windows-based servers
    "..\\..\\windows\\win.ini",    # Windows backslash notation
]

# Iterate over each payload and send the HTTP GET request
for payload in payloads:
    url = base_url + payload
    try:
        response = requests.get(url, timeout=5)
        # Check for common indicators in the response
        if response.status_code == 200:
            if "root:" in response.text or "[extensions]" in response.text or "for 16-bit app support" in response.text:
                print(f"[+] Possible vulnerability detected with payload: {payload}")
                print(f"URL: {url}")
            else:
                print(f"[-] Payload did not return expected result: {payload}")
        else:
            print(f"[-] Non-200 status code for payload {payload}: {response.status_code}")
    except requests.exceptions.RequestException as e:
        print(f"[!] Request failed for payload {payload}: {e}")

Code Walkthrough:

Payloads: A list of common traversal payloads designed to access sensitive files on Unix and Windows systems.
Request Execution: The script sends a GET request for each payload to the vulnerable URL.
Response Analysis: It checks if the HTTP status is 200 OK and searches for key indicators like "root:" (Unix) or configuration markers from win.ini (Windows).
Error Handling: Basic error handling is included to catch request exceptions.

Note: Modify base_url to match your target application. Always ensure you have permission before testing.

Interpreting the Results

When analyzing the responses:

Valid Indicators: A successful path traversal attack may reveal file content that should not be publicly accessible. For example, /etc/passwd usually contains user account information starting with lines like root: x:0:0:root:/root:/bin/bash.
False Positives: Some applications may return a 200 status code even if the file does not exist, often displaying a generic error message. Use multiple payloads and compare responses.
Error Codes: HTTP status codes such as 403 Forbidden or custom error messages can still indicate the presence of traversal attempts, even if access is ultimately denied.

Mitigation and Best Practices

While this post focuses on testing for vulnerabilities, it is equally important to understand mitigation techniques:

Input Validation: Rigorously sanitize all user-supplied input. Avoid directly using user inputs in file paths.
Whitelist Approaches: Only allow file access for a predefined list of safe file names.
Use Framework Security Features: Many modern web frameworks provide built-in functions to handle file paths safely.

For developers and security professionals alike, understanding both sides of the equation—identifying vulnerabilities and applying robust mitigations—is key to improving overall security posture.

Conclusion

Relative path traversal vulnerabilities can have severe consequences if left unchecked. This deep dive has walked you through manual testing techniques, from identifying input vectors to injecting various payloads, and even provided a Python script to help automate the testing process. We hope this article adds valuable insights and practical skills to your penetration testing repertoire.

Stay tuned for more technical deep dives in our Learn Pentesting series, where we explore additional vulnerabilities and testing methodologies.

Happy Testing!