top of page

What is a Path Traversal Attack?

Updated: Dec 2

avoiding path traversal

Path Traversal is one of the most prevalent attack techniques against web applications and is also part of the OWASP Top 10 list of web-based attacks. It is also very common and simple to exploit, with consequences ranging from file system access, information disclosure and Remote Code Execution.

What is a Path Traversal attack?

It is an attack technique that is intended towards accessing file system locations (files, directories) that are outside of the container on which the web application is running in. It can lead to leaking information about the system hosting the web application, such as sensitive files (config files, environment variables, files hidden from the web application etc), information (such as application source code) and even Remote Code Execution.

Impact of a Path Traversal attack

A Path traversal attack can have serious implications, if exploited:

  • Leak of sensitive files and information on the filesystem

  • Remote-code execution

  • Creation of backdoors into the affected server

How does an application become susceptible to a Path Traversal attack?

Path Traversal is a consequence of improper input sanitization (at the application level) when dealing with flows that access the filesystem (such as reading of files, images and scripts). Creative constructs of payloads for those parameters can allow for traversing different locations across the filesystem, that are outside the location of the web server root.

At its core, Path Traversal payloads involve parameters denoting paths to locations away from the root web application directory. The simplest payload is as below:


This denotes access to one level above the base web application directory.

Different types of Payloads for a Path Traversal attack

Regular payloads http://<base-application-url>/?file=../ -> Nix environments http://<base-application-url>/?file=/etc/passwd -> Absolute path http://<base-application-url>/?file=..\ -> Windows environments For exploits, variations of the relative and absolute path can be picked up and can work way up the levels to reach to different areas of the filesystem. Another technique can be to fuzz the directory names in a scan to see if they exist or not.

Stripped payloads http://<base-application-url>/?file=....//....//etc/passwd This is a non-recursive traversal payload that is stripped to ../../etc/passwd

Encoded payloads http://<base-application-url>/?file=..%2F..%2F..%2Fetc%2Fpasswd%20 The above example has a URL-encoded parameter that translates to ../../../etc/passwd In addition to a single encoding level, multiple encodings can be made for more creative exploits.

Payload starting from expected path http://<base-application-url>/?file=/var/www/images/../../../etc/passwd In this case, the web application has validation in the input parameter that mandates input file to be present in the /var/www/images directory. The above payload bypasses that validation.

Null-byte character These payloads are used to bypass specific file restrictions for input file (such as a requirement for the file being a PNG file). http://<base-application-url>/?file=../../../etc/passwd%00.png The null byte at the end is discarded after validation.

Basic Vulnerable App Exploit and Impact

$file = $_GET['file'];

Accessing through the following exploit

GET /dirtraversal.php?file=../../../../etc/passwd
Printing contents of /etc/passwd through path traversal
Printing contents of /etc/passwd through path traversal

Similar payloads to get the same result


How do you prevent a Path Traversal attack?

Path Traversal is a fairly simple thing to solve. At its core involves proper sanitization of user input.

  1. Preferably, do not have user input for calls to the filesystem.

  2. Check user input -> Should contain only allowed values and input containing traversal characters should be stripped off. Accept the known good input.

  3. Canonicalize user input to verify it starts with an expected base directory.

A simple way to do accomplish this is to compare actual paths on the file system and determine whether there is a traversal mechanism in place. This can be done by resolving to an actual path on the filesystem and then comparing with the resolution of the actual file path.


$file = $_GET['file'];
$base_path = "/opt/homebrew/var/www";
$file_path = $base_path . $file;
$real_path = realpath($file_path);
if($real_path === false || strpos($real_path, realpath($base_path) !== 0))
        echo "File not found!";

The above code ensures that the file path of the parameter exists in the /opt/homebrew/var/www folder, which is not the case if there is path traversal in place, resulting in the following output.

Preventing path traversal through base path
Preventing path traversal through base path


As shown, Path Traversal is a fairly common attack, being part of the OWASP Top 10 list of attacks. It is mostly caused due to developer ignorance and can cause a whole world of pain if exploited, with sensitive information disclosure and remote code execution being fairly common results of such attacks.

It is fairly easy to solve and can be done with checks and balances for user input and ensuring whether filesystem access for user-input is even needed in the first place. If those measures are taken, we will be one step further in securing our web applications.

At BUZZ, we have found various applications susceptible to Path Traversal attacks, which can lead to serious implications for the organizations business and reputation, if exploited. Check once or contact BUZZ experts for securing your applications and systems.

bottom of page