0 0
Read Time:5 Minute, 12 Second

Every day we hear of a new technological invention — to the extent that many important processes, like bank transactions, information exchanges, and messaging have all become digital. However, with increased digitization comes increased security threats, especially from hackers.

When building a confidential data-based system, you must make sure it is absolutely secure. To ensure this, you need to plug any vulnerabilities that may have arisen during development. One such vulnerability is Path Traversal.

What is Path Traversal?

Path traversal, also known as directory traversal, is a web security risk that allows the attacker to read unrecognized files on the application server. This may include application code and data, credentials of reverse programs, and sensitive system files.

In some cases, the attacker may be able to write conflicting files to the server, modify application or behavior data, and ultimately control the server. This is mainly an HTTP attack.

Web server/web applications run according to a webroot directory and its configuration. The exact method depends on the application and the web server, but standard webroot references include Apache /var/www for Linux or macOS and C:\Inetpub\www\root for Windows.

An Example of Path Traversal

There are multiple ways an attacker can attack your system. As path traversal is an HTTP attack, it can be through any HTTP method like GET, POST, PUT, etc.

Usually, in a web app, you set your input method as GET or POST method; for example, if you need to get user information, you would create a form through which the user would input their information.

Let’s look at a quick example. Suppose you have a web application with many dynamic pages that are configured at the server level. At the browser level, it comes via a GET or POST method. Here’s how the attacker might target your application:

  1. Let’s assume this is your dynamic URL: https://your-app.com/show.asp?view=homepage.html
  2. Your server will receive a request for show.asp page when someone visits your URL through a web browser. With this you will also get params view=homepage.html
  3. The server will send the required page written in show.asp
  4. The attacker sees that show.asp can get any file that is provided in view params of URL.
  5. The attacker sends a request for: https://your-app.com/show.asp?view=../../../../../../../Windows/system.ini (this is the system file for Windows, it has all system-related information)
  6. In above URL, ../ tells the system to go up one directory. So, by traversing the path, the attacker can gain access to your confidential system files.

Now let’s look at this second example with the Unix operating system.

  1. When you open this URL  www.your-app.com/user-info.php/, the server will get that page from /var/www directory.
  2. When someone opens this site, they see one form which they need to fill. For a path traversal attack, the attacker can try to access the system file /etc/passwd. This is a text file containing the system’s accounts and related information at this URL:

https://your-app.com/user-info.php?file=../../etc/passwd

  1. If the attacker reaches ../../etc/passwd and gets access to /var/www, they can change the program and retrieve whatever information they want as this is the heart of the system.

Direct Path Traversal:

  1. Suppose your system has these kinds of URLs:

http://your-app.com/homepage.php?f=list

http://your-app.com/homepage.asp?f=test

  1. An attacker can change a bit in the URL:

http://your-app.com/homepage.php?f=/var/www/html/get.php

http://your-app.com/homepage.asp?f=/etc/passwd

This is how an attacker can reach your confidential files and modify your system.

To prevent this, you must first check for path traversal vulnerabilities.

Checking for Path Traversal Vulnerabilities

Path traversal risk arises when applications use user-controlled data to access files and directories on an application server or other secure backup file system. By submitting an invalid input, the attacker may cause incomprehensible content to be read from, or written to, anywhere in the file system. This often enables the attacker to read sensitive information from the server, or override sensitive files, which ultimately leads to abrupt command execution on the server.

The best way to check if your website or web application is at risk of path traversal attacks is by using a Web Vulnerability Scanner. A Web Vulnerability Scanner scans your webpages to detect security risks and logical flaws. You can also use Burp, which is a tool you can configure with your web browser.

Protecting Against Path Traversal

To prevent path traversal, you need to take care of two things: your web server, and its configuration.  Both are related to each other, you just need to execute the right steps to avoid this vulnerability.

In an earlier example you saw how an attacker can reach our confidential files. To prevent this attack, you need to check for path traversal vulnerabilities. Here’s how:

  1. Sanitize Filename Parameters: if you need to fetch file names or methods from user input, make sure they are properly scanned by valid names and/or characters. Blacklisting filters ../ and the same string is not recommended because there are too many ways to bypass it. You can hard-cod already defined file extensions like this:
<?php
include($_GET['file'] . '.html');
?>
  1. Principle of Least Privilege: To keep your web servers safe, only provide necessary permissions to users or processes. Through this, you can make sure that a server process can only access the references they need. Consider using the chroot jail system when working on Unix.

In addition to these two major steps, you can also go the extra mile by not accepting user inputs while working with system calls. Preventing the user from asking for all paths will also help secure your application, as you can block paths through permissions.

For more security, you can host your confidential documents on a different web server with additional precautions. This creates two-layer security, which is much safer, and you can easily identify public and private documents.