How to Prevent Directory Traversal Attacks

What Is Directory Traversal?

On a web server, web applications are executed relative to the web root directory (also called the web document root). The exact path depends on the operating system and web server, but common web root directories include /var/www for Apache on Linux and C:\Inetpub\wwwroot for IIS on Windows.

A bug in the web server software may allow the web server process to access files outside the web document root. If a web application also uses file names taken from user inputs without proper input validation, this could open up a path traversal vulnerability. Instead of valid file names, an attacker can then enter relative or absolute file paths to access arbitrary files, including application source code, system files, server logs, and other files containing sensitive information. If combined with some kind of file upload vulnerability, directory traversal can even lead to remote code execution.

Path traversal attacks are closely related to local file inclusion vulnerabilities. An application vulnerable to a local file inclusion attack loads its modules or resources based on file names passed via unvalidated inputs. In such cases, an attacker can use path traversal to replace the names of application component files with paths to other files in the file system.

Directory Traversal Examples

To take a simple example, let’s say we have a “Show File” button that opens the following URL when clicked:

https://www.example.com/show_file.php?file=report.txt

For a classic directory traversal attack, the attacker can try to access the system file /etc/passwd (assuming a Linux/UNIX system) by visiting the URL:

https://www.example.com/show_file.php?file=../../etc/passwd

If the application simply takes the value of the file parameter from the URL and passes it to a system call, it would traverse the relative path ../../etc/passwd starting from /var/www and ask the system to load the password file. This technique is also called a dot-dot-slash attack, because it often uses the special characters ../ (or \.. on Windows) to climb to a higher-level directory.

The vulnerability is not restricted to passing file names directly in URLs. For example, a website might store user preferences in a cookie, as in the following PHP code to load a skin:

<?php
    $skin = 'default.php';
    if (isset($_COOKIE['SKIN'])) {
        $template = $_COOKIE['SKIN']; 
    } 
    include("../resources/skins/" . $skin); 
?>

In this case, the file name is stored in a cookie called SKIN and simply concatenated with a path. An attacker could exploit this by spoofing the cookie value and sending the following HTTP request:

GET /index.php HTTP/1.0
Cookie: SKIN=../../../etc/passwd

This value would be appended to the path, causing the web server to execute the following include() call to climb into the /etc directory and load the password file:

include("../resources/skins/../../../etc/passwd");

There are also many ways of encoding the path traversal string to evade naive character filtering, for example by writing ../ in URL encoding as %2e%2e%2f.

Avoiding Path Traversal Vulnerabilities

Path traversal attacks rely on two vulnerable elements: the web application code and the web server configuration. By taking care to avoid vulnerabilities in both areas, you can mitigate the majority of such attacks.

Vulnerable web applications use unvalidated user inputs in file names and paths. Passing around raw file names and paths is always a bad idea not just for reasons of security (apart from path traversal, it may introduce cross-site scripting), but also because it makes applications fragile and harder to maintain. Modern applications generally avoid this by using URL mapping to separate the URLs from the underlying files. In fact, if you use a CMS or web development framework, this is often the default approach. A related solution is to store files in a central database, not directly in the web server file system, and define your own resource names used to access them.

If you do need to take file names or paths from user inputs, ensure they are properly sanitized by whitelisting permitted names and/or characters. Blacklisting characters to filter out ../ and similar strings is not recommended because there are many ways to bypass it. See the OWASP page on testing for directory traversal vulnerabilities for a long list of known exploits.

To mitigate the vulnerability on the web server side, ensure you are using up-to-date web server software. The web server process should also run with the minimum necessary privileges and only have access to directories that the website or application actually needs. For Linux/UNIX systems, you may want to consider running the web server in a chroot jail to contain any path traversal attacks that do succeed.

To detect these and many other vulnerabilities, regularly scan your websites and web applications with a high-quality dynamic application security testing solution. Invicti detects hundreds of vulnerabilities, including file inclusions with path traversal.