Introduction

Websites are built to serve different purposes. It can consist of a few to several hundred static web pages. One such example of a static web page is an About Us page. You’ll find it on almost every website. Developers often include static web pages directly from the directory to be displayed on the web page. These can be pdf files, word documents, and even standard php files and scripts. This provides a very easy interface to the developers as a single piece of code can be utilised to fetch a lot of files even if something changes, you only need to change the file name, and there is no need to update all the links. One particular example we came across was that of a website including en.php file, whose work was to convert all the text provided in the currently open page to English. The task will be extremely time-consuming if they are required to convert all of the files in English and other languages. Simply passing the file name into the en.php will result in the file being entirely shown in the English translation. It will solve a lot of time and work around Whenever the developers fail to perform proper backend checks on the file names or URLs that are being included or fetched on the webpage, problems arise. Consequently, the result is unpredictable when an attacker attempts to include sensitive files. Path Traversal Vulnerabilities, also known as Local File Inclusion, are a type of vulnerability that can be exploited.

What is path traversal vulnerability, and why does it occur?

A path traversal vulnerability on your web server allows an attacker to gain access to files on your web server that they should not be able to access by default. To accomplish this, they deceive the web server or the web application running on it into returning files that are not contained within the web root folder. This occurs most frequently when no validations are applied to the parameter that is getting the file from the server. Consider the code snippet from our hypothetical site, example.com

We can see that the site expects a GET parameter called the file and stores its value in the $file variable. If it is set, the backend script will try to include it from the page's directory, provided that it exists. If the file parameter isn’t set; it’ll show you the default index.php page.

Now consider the URL provided:

https://www.example.com/file?file=page1.php

As we can see, the file parameter is set; it’ll extract its value (i.e., page1.php) and check if the page with this file name exists in the directory. If it does, the page will be displayed. This is because of the include method being used.

The script will try to execute the following query: include(pages/page1.php)

Looks like everything is working perfectly. Let’s get a bit crafty. What if we try a fancy payload that tries to include the passwd file?

https://www.example.com/file?file=../../../../../../../etc/passwd

If the value of the file parameter contains a pair of (..), it can be used to escape from the subfolder in which it is located. There will be a lot of dot dot Slash (../) Notation, which will lead to the root directory, and we can thus include the files from the root directory. Because we have used the /etc/passwd directory, the passwd file from the /etc directory will be included.

The script will try to execute the following query:

include(pages/../../../../../../../etc/passwd)

As there are no backend checks involved, it’ll include the contents of the /etc/passwd file and fetch them at your disposal.

Path Traversal vulnerabilities arise due to various reasons

1. Inclusion of files from the server using unsafe methods
2. No back end filtering and validation applied.

Testing for path Traversal Vulnerability

Before we can begin testing for path traversal vulnerabilities, there are two things to consider:

1. The parameter which accepts the file name.
2. Fingerprinting the web server.

Case 1:

Enumerating parameter(s) that accept the file name

Most online applications can be configured to accept a couple of parameters, with each parameter performing a specific activity or functionality. Many times, you will be unable to list all of the parameters because of a technical limitation. Let’s discuss all of them at length.

• A web application that accepts a few parameters allows you to try to guess what functionality is connected with each parameter. For example, some may be used to filter out the most recent products, others could be used to sort according to a set of criteria, and so on. If you figure out which option is accepting a file name, you can experiment with it to see if you can include some default files that are already present in the Linux or Windows operating systems. Page, view, file, and other commonly used parameters are examples of what can be done with them.
• In certain scenarios, you can’t entirely be sure if an application accepts a file parameter, you can try to brute force or guess it. In case you opt for the brute force approach you can try tools like ffuf and wfuzz.

Case 2:

Fingerprinting the web server

What would you think if you discovered an LFI vulnerability but were unable to exploit it? Perhaps there is whitelisting or blacklisting in place, or perhaps you are attempting to include payloads that aren’t appropriate for the situation. What do I mean by including wrong payloads in my analysis? What if you are trying to include files that are a part of a Linux System like, /etc/passwd, /etc/hosts, but in reality, the web server is hosted on a windows platform? So, to save you some time and frustration, also try to fingerprint the web server. This can be accomplished using extensions like wappalyzer, tools like nikto, nmap and even by looking at the headers of the responses. Once you have found the server, you can use payloads only specific to that Operating System.

In some test scenarios, even if you spot an LFI, you might not be able to exploit it. In that scenario, you can try to:

1. Use of URL encoded payloads. For example, ../ can become %2e%2e%2f
2. Double URL Encode
3. Use wrappers if the application is made in PHP

Remediation

Just because of unsafe coding practises or logic issues, an attacker can have access to sensitive files that can make it easier for him to compromise the web application. It is therefore important to implement the following remediation techniques:

1. Never trust the user input.
2. Use blacklists and whitelists of the file that are needed to be included. Mostly the whitelisting should have to be maintained
3. Disable the use of PHP wrappers if not necessary.
4. The use of a WAF can be helpful.