Threats and Vulnerabilities

Directory Traversal: Examples, Testing, and Prevention

Directory traversal, or path traversal, is an HTTP exploit. It exploits a security misconfiguration on a web server, to access data stored outside the server's root directory. A successful directory traversal attempt enables attackers to view restricted files and sometimes also execute commands on the targeted server. 

Directory Traversal: Examples, Testing, and Prevention
Admir Dizdar
August 23, 2021
6 minutes

What Is Directory Traversal?

Directory traversal, or path traversal, is an HTTP exploit. It exploits a security misconfiguration on a web server, to access data stored outside the server’s root directory. A successful directory traversal attempt enables attackers to view restricted files and sometimes also execute commands on the targeted server. 

Typically, a directory traversal attack exploits web browsers. This means that all servers accepting unvalidated input data from web browsers are vulnerable to the attack. To launch this attack, threat actors often scan through a directory tree, which is where they can locate paths to restricted files on web servers.

In this article:

How Are Directory Traversal Vulnerabilities Exploited?

The web server receives a  request and appends the ../../etc/hosts relative path, specified by the user, to a directory of web pages (/var/www/). This creates a full path: /var/www/html/../../../etc/hosts

In systems like UNIX, the element ../ traverses a directory in the file system, and can give a malicious user access to the file /etc/hosts.

Malicious users can use this attack method to access secrets and sensitive information like passwords and database credentials. They can also exploit the vulnerability to carry out further enumeration of the system and obtain the information they need to enable a combined attack through vectors like LFI and RFI.

Learn more in our detailed guide to directory traversal attack.

Directory Traversal Examples

Simple Directory Traversal (dot-dot-slash Attack)

The simplest example of a directory traversal attack is when an application displays or allows the user to download a file via a URL parameter. 

For example, if the user provides the file name document.pdf, and the website downloads the PDF to the user’s computer via this URL:

https://www.vulnerable.com/download_file.php?file=document.pdf

If the website is hosted on a Linux system, website files are typically stored in /var/www which is two directories above the root. The attacker can exploit this, passing this as the file name:

../../etc/passwd

If the application does not sanitize inputs, it uses the attacker’s string directly in a system call, switches to the root and then allows the attacker to access the /etc/ directory. It then allows the attacker to access the protected passwd file. 

A similar attack can be performed on a Windows system using the string ..

Using Cookies for Directory Traversal

In many cases, cookies reference directories on a web server to load files required for a website. This exposes the site to a directory traversal attack. For example, consider a cookie that accesses a file to load a new design template for a website:

<?php
    $design = 'new-design.php';
    if (isset($_COOKIE['DESIGN'])) {
        $template = $_COOKIE['DESIGN']; 
    } 
    include("../resources/" . $design); 
?>

In this scenario, the name of the file is stored in the DESIGN cookie and appended to a path. Because there is no validation of the $design variable an attacker can send a GET HTTP request that modifies the cookie value to DESIGN=../../etc/passwd

The web server would then perform the following system call, loading the passwd file instead of the design template.

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

Path Traversal Prevention

Here are several ways you can use to prevent path traversal attacks: 

  • Developers should validate user input accepted from browsers. Input validation can help ensure that attackers are restricted from using command techniques, like SQL injection, which violate access privileges and may grant attackers access to a root directory. 
  • Applications should use filters to block suspicious user input. Most web applications employ filters to block URLs that contain commands, as well as escape codes commonly employed by attackers. 
  • Administrators should keep software up to date, including web server software and the underlying operating system, and apply all security patches. The practice of regularly patching software can significantly reduce security risks and reduce the chance of exploitation.

Related content: Read our guide to misconfiguration attacks.

Testing for Directory Traversal Vulnerabilities

There are several testing techniques that can help you identify directory traversal flaws and vulnerabilities in your web applications. Here are several methods recommended by the web application security project (OWASP):

Input Vectors Enumeration

Enumeration is a technique used to detect attack vectors in systems. Input vector enumeration offers a systematic evaluation of all input vectors. The goal is to learn which specific part of a web application is vulnerable to input validation bypassing.  

Testers can do this by itemizing all application components that can accept user input, such as HTTP, POST and GET calls, HTML forms, and file uploads. Here are several aspects to consider when testing this aspect:

  • Can you find request parameters which can potentially be used for file-related operations? For example: https://mysite.com/getUserProfile.jsp?item=abcd.htm
  • Can you detect any unusual file extensions? Such as: https://mysite.com/index.jsp?file=content
  • Do you see any interesting variable names? For example:  https://mysite.com/main.php?home=index.htm

Testing Techniques

The next phase of this security testing process involves analyzing all input validation functions in the tested web application. 

To quickly test an existing web application for directory traversal vulnerabilities, you can use the following technique:

  • Insert relative paths into files existing on your web server. For example:../../../../../../etc/passwd on Linux servers. 
  • Check whether a system is vulnerable to certain tricks like a ../ removal that uses percent-encoded values like %2e%2e%2f
  • You can check for file extension by adding a null byte like %00 before you insert a valid extension. 

Manually implementing the above techniques can be time consuming and error prone for large web applications. Instead of doing this manually, you can use an automated tool. The following technologies are commonly used to automatically analyze input validation:

  • Static application security testing (SAST)—these tools review the source code of the application when it is not running. SAST checks try to identify evidence of known insecure practices and vulnerabilities. SAST solutions employ white-box techniques.
  • Dynamic application security testing (DAST)—tools that communicate with the application through its front-end in order to identify security vulnerabilities. A DAST tool does not need any access to your source code. Rather, it simulates real attacks using a black-box strategy. Security checks are performed while executing or running the application or code under review. It also involves fuzzing, a technique used to submit random and malformed data as input to the web application, using it to uncover directory traversal vulnerabilities.

What Our Customers Say About Us

"Empowering our developers with Bright Security's DAST has been pivotal at SentinelOne. It's not just about protecting systems; it's about instilling a culture where security is an integral part of development, driving innovation and efficiency."

Kunal Bhattacharya | Head of Application Security

"Bright DAST has transformed how we approach AST at SXI, Inc. Its seamless CI/CD
integration, advanced scanning, and actionable insights empower us to catch
vulnerabilities early, saving time and costs. It's a game-changer for organizations aiming to
enhance their security posture and reduce remediation costs."

Carlo M. Camerino | Chief Technology Officer

"Bright Security has helped us shift left by automating AppSec scans and regression testing early in development while also fostering better collaboration between R&D teams and raising overall security posture and awareness. Their support has been consistently fast and helpful."

Amit Blum | Security team lead

"Bright Security enabled us to significantly improve our application security coverage and remediate vulnerabilities much faster. Bright Security has reduced the amount of wall clock hours AND man hours we used to spend doing preliminary scans on applications by about 70%."

Alex Brown

"Duis aute irure dolor in reprehenderit in voluptate velit esse."

Bobby Kuzma | ProCircular

"Since implementing Bright's DAST scanner, we have markedly improved the efficiency of our runtime scanning. Despite increasing the cadence of application testing, we've noticed no impact to application stability using the tool. Additionally, the level of customer support has been second to none. They have been committed to ensuring our experience with the product has been valuable and have diligently worked with us to resolve any issues and questions."

AppSec Leader | Prominent Midwestern Bank

Book a Demo

See how Bright validates real risk inside your CI/CD pipeline and eliminates false positives before they reach developers.

Our clients:
SulAmerica Barracuda SentinelOne MetLife Nielsen Heritage Bank Versant Health