File Path Traversal Vulnerability

A beginner-friendly look at how improper file handling allows attackers to bypass security and wander through a web server's restricted directories.

INTRODCUTION

Imagine a restricted library where you aren't allowed to browse the shelves yourself. Instead, you hand a slip of paper to a librarian with the name of the book you want, and they fetch it for you from the public archives. If you write down "History of Rome" they bring you the book.

But what if you write : "Walk past the archives, go through the 'Staff Only' door, enter the manager's office, and bring me the library's financial records." If the librarian blindly follows those exact steps without checking wether you have the clearance to ask for that particular record, you have just bypassed their security. That is exactly how a Path Traversal (or Directory Traversal) vulnerability works on a web server.

At its core, Path Traversal is a web security flaw that allows an attacker to read files on a server that they were never supposed to access. When a website takes user input like a filename used to load an image (image.jpg), it assumes you are only asking for files inside its designated public folder.

However, if the application doesn't properly sanitize that input, an attacker can manipulate the request. By injecting special sequence characters like ../ (which means "go up one folder"), an attacker tricks the server into stepping backward out of the public web directory. With enough ../ sequences, they can wander into restricted areas of the server's operating system to steal sensitive data, application source code, or critical system files like /etc/passwd. To better understand this vulnerability, we will walk through a real-world example using a PortSwigger Web Security Academy lab.

How it works under the hood (the mechanics)

To understand why our overly helpful librarian gets tricked, we have to look at how a web server actually fetches files behind the scenes.

Imagine our library has an online portal where users can read digital excerpt of abooks. The URL to load an excerpt might look something like this:

https://city-library.com/readExcerpt?file=history-of-rome.txt

On the backend, the server takes that file parameter and appends it to a specific base folder where all the public reading materials are stored. The underlying code essentially executes a command like this:

File path = /var/www/library/public_archives/ + [USER_INPUT]

If a normal reader requests history-of-rome.txt, the server looks inside /var/www/library/public_archives/history-of-rome.txt, find the text and will display it on the webpage. The system works perfectly fine as it should be.

The Attack Vector

The vulnerability occurs when the application blindly trusts the user's input without checking for directory traversal sequences, specifically the "dot-dot-slash" (../). In operating systems like Linux, ../ is a standard command that simply means "go up one directory level."

If an attacker intercepts the web requests and modifies the file parameter to ../../../../etc/passwd, the server's backend code pieces it together like this:

File path = /var/www/library/public_archives/../../../../etc/passwd

Because the server does not sanitize the input, it executes the traversal exactly as written. Here is the step-by-step breakdown of how the server accesses files outside its folder.

• The first ../ moves the server up from /public_archives to /library
• The second ../ moves the server up from /library to /www
• The third ../ moves the server up from /www to /var
• The fourth ../ moves the server up from /var, dropping it right at the system's root directory.
• From the root directory, it navigates into the /etc folder and opens the passwd file.
• Instead of returning a chapter on Roman history, the server serves up the /etc/passwd file, exposing core system data and user accounts to the attacker. Just like that, the restricted public archives have been entirely bypassed !!

Lab Walkthrough

To see this in action, we are going to exploit the "File path traversal, simple case" lab from PortSwigger's Web Security Academy.

Lab link : https://portswigger.net/web-security/file-path-traversal/lab-simple

Phase 1: Intercepting the Request

• First, we enable the Burp Suite extension in our browser to intercept the website's traffic.

• While browsing the shop's homepage, we capture the incoming HTTP requests in Burp Suite's Proxy tab.
• We can clearly identify the vulnerable endpoint as the application requests product images using the format GET /image?filename=59.jpg.

Phase 2: Preparing the Attack

• To manipulate this specific request without refreshing the whole page, we right-click the intercepted GET request.
• We select "Send to Repeater" (or use Ctrl + R) to isolate the request for testing.

• Burp Repeater now provides a dedicated workspace where we can easily edit the filename parameter.

Phase 3: Injecting the Payload

• In the Repeater tab, we delete the original 59.jpg value and inject our directory traversal payload: ../../../etc/passwd .
• After sending the modified request, the server responds with an HTTP/2 200 OK status instead of throwing an error.
• Instead of returning a picture, the server successfully dumps the contents of the /etc/passwd file straight into our response window, revealing internal system accounts like root, daemon, and carlos.

Remediation: Locking the Library Doors (The Fix)

Now that we know how an attacker tricks our digital librarian, how do we fix it?

The absolute best defense against Path Traversal is to never pass user-supplied input directly into file system APIs. If a developer must allow users to input filenames, here are the industry-standard ways to secure the code:

1. Allowlisting (The Ultimate Defense)

Instead of trying to guess every bad payload an attacker might try (like double URL encoding or null bytes), use an allowlist. Implement a strict policy where the application only accepts predefined safe characters (like alphanumeric characters only) or specific, known filenames. If an input contains a slash / or a dot . , reject it immediately.

2. Path Canonicalization

Before the server opens any file, it should resolve the absolute path and verify its destination. Languages have built-in functions designed exactly for this such as realpath() in PHP or getCanonicalPath() in Java.

The code should look at the full path after the user input is processed:

• If the final resolved path is /var/www/library/public_archives/history-of-rome.txt, the server allows it.
• If the final resolved path attempts to escape to /etc/passwd, the server catches it, blocks the request, and flags it as malicious.

3. Permissions and Sandboxing

Run the web server with the absolute minimum privileges required (the Principle of Least Privilege). The account running the web service should never have read access to sensitive operating system files like /etc/passwd in the first place. Even if the application logic breaks, the operating system security policies will stop the attacker from reading restricted files.

CONCLUSION

Path Traversal might be a foundational vulnerability, but it remains highly impactful if left unchecked. By understanding the underlying mechanics of how servers interpret file paths and applying strict input sanitization, developers can ensure their digital librarians only serve the public books they are meant to be shared.