Imagine being on a website, browsing through articles and hoping over some pictures, only to find out that you can actually see things you’re not supposed to be seeing.
I am talking website sensitive data, back-end code and system credentials.
This is exactly what path traversal vulnerability can do.
In this article we are going to get to know how this vulnerability work, how to read files using it, we will also discuss some tips and at the end we are going to solve all portswigger labs about this vuln, let’s get started.
So what is path traversal?
Put in simply, path traversal (AKA directory traversal) is a web application vulnerability that allows the attacker to read (and in some cases modify or delete) arbitrary files that are located on the web app server, outside the web root folder
How to use this vulnerability to read files?
Let’s say we’re reading a blog, and this blog has images on its page. Usually, the images are loaded from the server at this location /var/www/images/ using an HTML like this: <img src="/get-image?filename=someimage.png">
The problem is, the attacker can easily read other files, /etc/passwd for example, by requesting the following URL:
http://website.com/get-image?filename=../../../etc/passwd
So what happens is that the server loads from /var/www/images/../../../etc/passwdwhich is basically just /etc/passwd , because the sequence ../ tells the server to step up one level in the directory structure. And just so, the application reads the contents of /etc/passwd
On unix-based operating systems, this is the standard file that contains details about the users that are registered on the server. However, you can really read any file you want using the same method. On windows, you can use ../ or ..\ as they are both valid path traversal sequences.
Some tips to consider while exploiting path traversal vulnerability.
Some applications may implement defenses against path traversal attacks, such as striping or blocking path traversal sequences from the user-supplied filename. However, some of them can be bypassed.
1- Absolute path traversal
You can sometimes directly reference to the file you’re trying to read, instead of using the whole sequence. For example: filename=/etc/passwd
2- Nested path traversal
When the application strips the inner file path traversal sequence, you might be able to use ….// or ….\/ as a basic nested traversal sequences, resulting in a clean ../ and successfully jumping a level in the directory structure.
3- Using null byte
As a form of security, many applications require user-supplied filename to end with a specific extension, such as .png . If this is the case then it’s possible to use a null byte to terminate the file path before the extension. For example: filename=../../../etc/passwd%00.png
4- URL encoding the path traversal sequence
In some cases, the server may strip away any path traversal sequences before passing it to the application. However, this kind of sanitization can be bypassed by URL encoding (or double URL encoding) the characters ../ , which gives us %2e%2e%2f when encoding it once, and %252e%252e%252f when double encoding it, and then writing the path of the file you want to read.
5- Using the whole path
Some applications may require you to use the whole path as a valid traversal sequence, as it expects the user-supplied filename to start with the original folder. As in example, instead of using filename=/etc/passwd , you could use filename=/var/www/images/../../../etc/passwd
The practical section.
Let’s apply what we’ve learnt so far. I’m going to solve all path traversal labs on portswigger, so after you’re done reading this article you can try solving them yourself.
Basically, these labs start with the same home page, and we’re going to work on modifying the product picture request. So for the sake of this vulnerability, i am going to do the whole first lab and for the other labs i’m going to start from the intercepting the request step, as they are all the same first steps.
1- Simple case
Lab link: https://portswigger.net/web-security/file-path-traversal/lab-simple
Accessing the lab shows us the home page of an online store.
Let’s look at one of the products
It shows a normal product page. However, intercepting the request that fetches the product image using burp shows the following:
Let’s send this to the repeater and modify the /image?filename= part and watch the response:
And the response shows the contents of /etc/passwd
And just like that, the lab is solved.
2- traversal sequences blocked with absolute path bypass
Lab link: https://portswigger.net/web-security/file-path-traversal/lab-absolute-path-bypass
Intercepting the product fetching request
For this lab, there is no need to provide the whole ../../../etc/passwd sequence as the application blocks traversal sequences but treats the supplied filename as being relative to a default working directory (lab description)
So basically, typing /etc/passwd instead of 15.jpg and sending the request should do the trick.
Here we go.
3- traversal sequences stripped non-recursively
Lab link: https://portswigger.net/web-security/file-path-traversal/lab-sequences-stripped-non-recursively
Intercepting the product picture request
For the sake of this lab, we’re told that the application strips path traversal sequences from the user-supplied filename before using it, which leads us to use the ….// sequence.
As i said earlier, we should be in /var/www/images/ by default, so what we’re going to do is step up 3 directories and then read the /etc/passwd file, so basically the sequence looks like this: ….//….//….//etc/passwd
Let’s try and send this and see what happens.
And the lab is solved :)
4- traversal sequences stripped with superfluous URL-decode
Lab link: https://portswigger.net/web-security/file-path-traversal/lab-superfluous-url-decode
So this lab is actually really cool, and i enjoyed solving it. I hope you enjoy solving it too!
Let’s intercept the request
What is the deal with this lab?
So this lab basically blocks the raw input that contains path traversal sequences, and then it URL-decodes the input before using it
we see that just URL-encoding the sequence ../../../ (which gives us %2e%2e%2f%2e%2e%2f%2e%2e%2f ) then putting /etc/passwd doesn’t cut it
so we have to double URL-encode the same sequence (../../../) and then put /etc/passwd after it.
Here we are.
5- validation of start of path
Lab link: https://portswigger.net/web-security/file-path-traversal/lab-validate-start-of-path
So for this lab, when the application receives the request, it expects the path to start with the default folder which is just /var/www/images/
As a result, the sequence should contain /var/www/images/ in it. Let’s get into it.
Let’s first intercept the request and send it to the repeater
We see that the default path is already present in the request, so we just have to remove 12.jpg and add ../../../etc/passwd
And the lab is solved.
6- validation of file extension with null byte bypass
And now, onto the final lab. For this one, the application validates the supplied filename and expect it to end with a specific extension.
Let’s begin be intercepting the request
The problem here is, we can’t just navigate to /etc/passwd by using the sequence ../../../ as it gives “No such file” response.
And we can’t also type ../../../etc/passwd.jpg because this isn’t what we want really :)
So the solution would be to use a null byte to bypass the validation of the file extension, with a sequence similar to this one ../../../etc/passwd%00.jpg
And we got the response we wanted.
Conclusion.
So this was the path traversal vulnerability. A simple, yet powerful way to read files on the application server.
I hope you found this article useful, and i hope you learned something new.
Thank you for reading and i will see you in the next one.
