WebApp 101

WebApps 101: Directory Traversal

Anytime that you notice the URL is calling on a file name, you should test to see if there is a directory traversal vulnerability.

Note: Majority of this content was taken from Portswigger Web Academy, but is not an exact copy/paste.

Table of Contents

  1. Table of Contents
  2. What is Directory Traversal?
  3. Testing for Directory Traversal
    1. Common Directory Traversal Paths
    2. Key Testing Payloads:
  4. Examples
    1. Example #1: Simple Case
    2. Example #2: Validation of Start of Path
    3. Example #3: Using a Null Byte
    4. Example #4: Traversal Sequences Stripped Non-Recursively
    5. Example #5: Traversal Sequences Stripped with Superfluous URL-Decode
  5. How to Prevent a Directory Traversal Attack

What is Directory Traversal?

Directory traversal (also known as file path traversal) is a web security vulnerability that allows an attacker to read arbitrary files on the server that is running an application. This might include application code and data, credentials for back-end systems, and sensitive operating system files. In some cases, an attacker might be able to write to arbitrary files on the server, allowing them to modify application data or behavior, and ultimately take full control of the server.

Testing for Directory Traversal

An easy way to test is to simply try and place ./ in front of the filename in the URL. If the page reloads and looks the same, and the special characters were not stripped out, it is a good indication that no filtering is taking place.

Common Directory Traversal Paths

  • For Unix: /../../../etc/passwd
  • For Windows: ..\..\..\windows\win.ini

Key Testing Payloads:

  1. See Example #1../../../../../etc/passwd
  2. See Example #1/etc/passwd
  3. See Example #2/var/www/../../../etc/passwd
  4. See Example #3../../../etc/passwd%00
  5. See Example #3../../../etc/passwd%00.png
  6. See Example #4....//....//....//etc/passwd
  7. See Example #5%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd
  8. See Example #5%25%32%65%25%32%65%25%32%66%25%32%65%25%32%65%25%32%66%25%32%65%25%32%65%25%32%66etc%25%32%66passwd


Example #1: Simple Case

Example: Say you have the following endpoint:

We could update it to look like this. If the page reloads and the characters are still present in the browser, you likely have a directory traversal vulnerability present.

You can then try to read files on the system, such as /etc/passwd by going to the following URL.

Another option may be to try just using the full path directly.

Example #2: Validation of Start of Path

But what if the URL already included the full path? You may be tempted to go straight to the direct path of the file you’re looking for. However, the webserver may be configured to only server files that have a path that begin within a certain directory. Because of this, you may still need to use the above mentioned method for browsing the directory structure.

Example: Let’s say your vulnerable URL is below.

You may be tempted to go straight to the full path of the file you wish to view, but this could return nothing depending on how things are configured. Instead, you’d be better suited using the following URL.

Example #3: Using a Null Byte

In older versions of PHP, a null byte (represented as %00) can be used to effectively comment out and strip any file extension that the web application may append to the filename. This can be very helpful when trying to execute a file that uses a file extension that is different from what the web app is intended to serve.

Example: Let’s say your vulnerable URL is below.

The webserver itself is adding the .png file extension to the end of the filename. This means that it is serving a file up in the present working directory named hacker.png.

This is problematic for us as hackers because we may want to read /etc/passwd (as an example) using the following URL.

When we go to this, the webserver will append .png to the filename, which tries to take us to /etc/passwd.png. We can get around this by specifying our file extension, and then appending %00 to the request.

In cases where the application does not automatically add the file extension, but checks to make sure it’s present, you may have to add it yourself. For example:

Example #4: Traversal Sequences Stripped Non-Recursively

In some cases, the web application may strip out traversal sequences (such as ../../ or ..\..\). In those cases, you can place the traversal sequences inside of each other, so that a sequence is still left behind once stripped out.

Example: Let’s say your vulnerable URL is below.

You may be able to get past this issue by using the following payload:

Example #5: Traversal Sequences Stripped with Superfluous URL-Decode

In some contexts, such as in a URL path or the filename parameter of a multipart/form-data request, web servers may strip any directory traversal sequences before passing your input to the application. You can sometimes bypass this kind of sanitization by URL encoding, or even double URL encoding, the ../ characters, resulting in %2e%2e%2f or %252e%252e%252f respectively. Various non-standard encodings, such as ..%c0%af or ..%ef%bc%8f, may also do the trick.

Example: Let’s say your vulnerable URL is below.

Trying to use the following payload may be blocked.

But URL encoding the special characters may bypass the block.

If that doesn’t work, try double URL encoding it.

How to Prevent a Directory Traversal Attack

The most effective way to prevent file path traversal vulnerabilities is to avoid passing user-supplied input to filesystem APIs altogether. Many application functions that do this can be rewritten to deliver the same behavior in a safer way.

If it is considered unavoidable to pass user-supplied input to filesystem APIs, then two layers of defense should be used together to prevent attacks:

  • The application should validate the user input before processing it. Ideally, the validation should compare against a whitelist of permitted values. If that isn’t possible for the required functionality, then the validation should verify that the input contains only permitted content, such as purely alphanumeric characters.
  • After validating the supplied input, the application should append the input to the base directory and use a platform filesystem API to canonicalize the path. It should verify that the canonicalized path starts with the expected base directory.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s