Directory traversal

A directory traversal attack aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on the filesystem; including application source code, configuration, and other critical system files.

In this lesson, you will learn how directory traversal works and how to mitigate it in your application. You will first use a directory traversal attack to hack a vulnerable web server. We will then explain directory traversal by showing you the backend code of that vulnerable server. Finally, we will teach you how to prevent directory traversal from affecting your code.

Ready to learn? Buckle your seat belts, put on your hacker's hat, and let's get started!

To increase revenue and survive until the next funding round, a company called startup.io decided to create a side product. Since the market for image hosting platforms has recently become a bit saturated, the firm made a call to build an app for managing to-do lists instead.

Sadly, their to-do app is vulnerable to directory traversal attack. Let's use a terminal window and curl to exploit the vulnerability. Our goal is to view the /etc/passwd stored on the backend server.

The application is hosted on https://todoapp.startup.io. First, let's try to curl a page we should have access to.

Copy the following into the terminal: curl https://todoapp.startup.io/public/about.html

We see the about.html page returned, which is to be expected. Notice that this HTML page is being served from the public directory.

Let's remove the about.html filename from this request and see if we can get a directory listing back.

Copy the following into the terminal: curl https://todoapp.startup.io/public/

Bingo! We've managed to list the files in the public directory. This is not a severe hack yet, since we're still in the public directory. However, showing a directory listing like this is a form of unnecessary information disclosure.

Since we can list files in the public directory, maybe we could also traverse to other directories and see their contents? Let's add a ../ onto the URL to break up to the parent directory. Run the following command:

Copy the following into the terminal: curl https://todoapp.startup.io/public/../

Uh oh, we've lost our directory listing and are back into HTML! Our attempt at performing directory traversal has been caught! Sanitization exists, and it caught our malicious effort. It looks like we've been taken back to the to-do app homepage.

Our hope is not lost yet! There is a different way to represent a . in the web world: URL encoding. Let's try to circumvent the sanitization by URL encoding the .s. Replace the .s with %2e as follows:

Copy the following into the terminal: curl https://todoapp.startup.io/public/%2e%2e/

Congrats! You've broken out of the public directory. We can now step up our game and access some sensitive information.

I've got a suspicion we're running as the root user, so let's aim big and try to access some sensitive system information. For example, let’s access the /etc/passwd file. To do this, run the following command:

Copy the following into the terminal: curl https://todoapp.startup.io/public/%2e%2e/%2e%2e/etc/passwd

Boom! We’ve managed to view the /etc/passwd file. Imagine what else we could disclose if we poked around the filesystem for a bit longer. Maybe SSL certificates? Or database passwords with read/write access to production databases?

Let's see what went wrong on the startup.io backend server, which allowed us to perform a directory traversal attack.

Essentially, the attack is accomplished by adding characters such as ../ into a URL that serves content from a directory structure. The content is usually served from a base directory, such as /public. An attacker can supply filenames that contain ../ or a URL encoded equivalent %2e%2e%2f. These URLs allow the attacker to break out of the base directory and view files stored in other folders on the filesystem.

To illustrate this, let's jump into the code. Below you will find the a function, which constructs a filesystem path from the URL. All files and directories returned by the function are served statically by the web server.

To illustrate this, let's jump into the code. Below you will find the a function, which constructs a filesystem path from the URL. All files and directories returned by the function are served statically by the web server.

To illustrate this, let's jump into the code. Below you will find the a function, which constructs a filesystem path from the URL. All files and directories returned by the function are served statically by the web server.

To illustrate this, let's jump into the code. Below you will find the a function, which constructs a filesystem path from the URL. All files and directories returned by the function are served statically by the web server.

To illustrate this, let's jump into the code. Below you will find the a function, which constructs a filesystem path from the URL. All files and directories returned by the function are served statically by the web server.

To illustrate this, let's jump into the code. Below you will find the a function, which constructs a filesystem path from the URL. All files and directories returned by the function are served statically by the web server.

We can use the “realpath” function to dereference the requested (relative) path, and return the absolute path of the file.

By defining a base path (or an array of allowable paths) in our program, we can compare them to the output of realpath and decide whether a request should be permitted or not. If the prefix paths do not match up, then our user could be attempting to access files they’re not supposed to!

Now the images may only be used if they reside within /var/www/html/site.com/images/, and it will not result in code injection, because we are using readfile() instead of include(). If the requested file doesn’t exist, or the path doesn’t begin with the one we specify, then this code will return a default placeholder.

The most robust way to prevent directory traversal attacks is to avoid relying on user-supplied input when dealing with the filesystem APIs. Unfortunately, this is easier said than done and might require rewriting a considerable chunk of your application.

A more realistic mitigation mechanism is to prevent the user-supplied directory from being higher up on the filesystem than the directory used to serve static content.

For example, if an application serves files from /wwwroot/public/, any canonical representation of the user requested path must start with /wwwroot/public/. Otherwise, the request could break out of the target directory.

The code example below shows how to normalize the user-supplied path and check whether it starts in the expected directory. To achieve this in JavaScript, use path.normalize or similar.

The path normalization will deal with malicious inputs such as https://todoapp.startup.io/public/../. However, we can still trick it by encoding the . character as %2e. To be fully protected, you need to sanitize your user-supplied data and get rid of unexpected inputs, for instance:

• Maintain a set of allowed filesystem paths and compare the user input against that set.
• Allow only alphanumeric characters and reject inputs that contain other characters.

If the above measures are impractical, consider disallowing dangerous characters explicitly. For example, the below code removes the URL-encoded characters from the user-supplied input.

Correct sanitization of user input is hard work and requires constant verification against newly discovered ways to bypass known protection methods. In almost all cases, it is a better choice to use a well-maintained open-source library.

For instance, to serve static files in JavaScript, consider using st. Another option is to build your application with web frameworks, such as express, which have built-in support for serving static content.

To decide which libraries to trust, use Snyk Advisor! Snyk Advisor provides information on a given package's popularity, community support, and security. Also, check your open source libraries with vulnerability scanners such as Snyk, which will notify you about all new vulnerabilities discovered in any libraries you are using, and will help you mitigate them easily.

To recap, to mitigate directory traversal in your codebase, avoid calling filesystem APIs with user-supplied data as input. If that is not practical, validate that the user-supplied path is a child of the directory which the application serves from. Remember to sanitize the input to prevent malicious payloads from tricking you through techniques such as URL encoding. Finally, instead of writing all the logic yourself, consider using popular open-source libraries which handle things for you.

st is a popular JavaScript library used for serving static files. In its early version, it was vulnerable to directory traversal, which actually posed a serious security threat for the entire NPM ecosystem.

The diff below is from the commit, which added the sanitization to catch directory traversal attempts with URL encoding.

Take the code tour to understand the fix.

The most robust way to prevent directory traversal attacks is to avoid relying on user-supplied input when dealing with the filesystem APIs. Unfortunately, this is easier said than done and might require rewriting a considerable chunk of your application.

A more realistic mitigation mechanism is to prevent the user-supplied directory from being higher up on the filesystem than the directory used to serve static content.

For example, if an application serves files from /wwwroot/public/, any canonical representation of the user requested path must start with /wwwroot/public/. Otherwise, the request could break out of the target directory.

The code example below shows how to normalize the user-supplied path and check whether it starts in the expected directory. To achieve this in Java, use Path.normalize or similar.

The path normalization will deal with malicious inputs such as https://todoapp.startup.io/public/../. However, we can still trick it by encoding the . character as %2e. To be fully protected, you need to sanitize your user-supplied data and get rid of unexpected inputs, for instance:

• Maintain a set of allowed filesystem paths and compare the user input against that set.
• Allow only alphanumeric characters and reject inputs that contain other characters.

If the above measures are impractical, consider disallowing dangerous characters explicitly. For example, the below code removes the URL-encoded characters from the user-supplied input:

Correct sanitization of user input is hard work and requires constant verification against newly discovered ways to bypass known protection methods. In almost all cases, it is a better choice to use a well-maintained open-source library.

For instance, consider building your web application with Spring Boot, which has built-in support for serving static content.

To decide which libraries to trust, use Snyk Advisor! Snyk Advisor provides information on a given package's popularity, community support, and security. Also, check your open source libraries with vulnerability scanners such as Snyk, which will notify you about all new vulnerabilities discovered in any libraries you are using, and will help you mitigate them easily.

To recap, to mitigate directory traversal in your codebase, avoid calling filesystem APIs with user-supplied data as input. If that is not practical, validate that the user-supplied path is a child of the directory which the application serves from. Remember to sanitize the input to prevent malicious payloads from tricking you through techniques such as URL encoding. Finally, instead of writing all the logic yourself, consider using popular open-source libraries which handle things for you.

Symbolic Links (or symlinks) link to another file or directory in the file system, for example ../ points to the directory above the current working directory. We can use os.path.realpath to dereference the symlinks, return the absolute path and restrict access to the current working directory. You can see here in the result, our injected path would be converted to a canonical path before joining with our working directory:

When combined with the working directory, it will produce an error because there is no nested directory /home/etc/passwd in the applications working directory and will not allow an attacker to traverse outside of the directory.

We can update our code (with some detailed comments!) to make it safer:

Golang’s filepath.Join() will return the specified path generated from the components. To restrict access to the current working directory, we should check that the logo file path is the same as the expected base filesystem path where the image files reside.

Let’s look at how to do this by walking through the remediated code shown below. Firstly, we generate the directory component for the base path separately and assign it to the basePath variable. We then generate the absolute file path for the logo by combining the basePath and query string parameter for the logo filename. To check what the directory for the logo is, we use the filepath.Dir() function, which returns the specified directory path of the logo file without the filename on the end. We can then compare if this directory is the same as the base path and reject any requests where it’s not what we expect. You can see here in the result, our injected path would be converted to a canonical path after joining with our working directory:

If our app’s base path is /opt/todoapp/images and the attack payload of ../../../etc/passwd is injected into the logo filename query string parameter, it will result in an error because the directory /etc/ is outside the base path directory of /opt/todoapp/images.

We can use the Path library’s functions to dereference relative paths, and return the absolute path of a file! The Path library has a function, Path.GetFullPath, which returns this absolute path:

By defining a base path (or an array of allowable paths) in our program, we can compare them to the output of realpath and decide whether a request should be permitted or not. If the prefix paths do not match up, then our user could be attempting to access files they’re not supposed to!

Now when the file is retrieved from the file system, we know that it’s being retrieved from a whitelisted (approved) directory - and so unless you’re storing sensitive information in that directory, your code is directory traversal free!

To learn more about directory traversal, check out some other great content produced by Snyk:

• If you want to discover more about the vulnerability present in st, watch our YouTube video and read our blog post
• Read our white paper on Zip Slip, a directory traversal vulnerability that results in remote code execution
• If the white paper got you worried, learn how to mitigate Zip Slip in your code-base with our cheat sheet