Directory Traversal -Web Application Penetration Testing

An HTTP exploit is directory traversal, also known as path traversal. In order to access data stored outside the server’s root directory, it takes advantage of a security flaw in a web server.

Attackers are sometimes also able to run commands on the targeted server after a successful directory traversal attempt allows them to read restricted files.

A directory traversal attack often takes advantage of web browsers. This implies that every service that accepts unverified input data from web browsers is open to attack. Threat actors frequently search through a directory tree to find routes to prohibited files on web servers before launching this assault.

On a web server’s file system, at a place known as the web document root, are the source code files that make up a website or web application (web root folder).

Typically, each website and online application has a subdirectory in the principal document root.

For instance, the default root folder on a Linux/UNIX server running the Apache web server software is /var/www, while the default document root on a Microsoft Windows server running IIS is C:inetpubwwwroot.

Application code that directly accesses files located someplace in the document root directory or a subfolder may occasionally need to be written by developers.

For Example, a developer could wish to save user-uploaded photographs and subsequently let other users view them. The programme would then open a certain picture and show it on screen after receiving the image filename from /var/www/my app/images/ as a user input parameter.

When a malevolent user includes an arbitrary file path in user input and uses special characters to access files from a different directory on the server, this is known as a directory traversal vulnerability. Dot-dot-slash characters are used for this, such as../ for Linux/UNIX or.. for Windows. These combinations provide relative path access to parent directories.

Although directory traversal is a common online application vulnerability, it is most frequently discovered in embedded web applications, such as remote administration interfaces or device management software. Even web servers themselves have been blamed for several route traversal problems.

The web server receives a request and appends the ../../etc/hosts relative path, specified by the user, to a directory of web pages (/var/www/). This creates a full path: /var/www/html/../../../etc/hosts.

In systems like UNIX, the element ../ traverses a directory in the file system, and can give a malicious user access to the file /etc/hosts.

This attack technique may be used by malicious people to get access to sensitive data, including passwords and database credentials. They can use the flaw to further enumerate the system and gather the necessary data to allow a combined assault using attack vectors like LFI and RFI.

When a user may download a file via a URL parameter, an application is displaying a directory traversal attack in its most basic form.

For instance, if a user enters the file name document.pdf and the website uses the following URL to download the PDF to the user’s computer:

https://www.vulnerable.com/download_file.php?file=document.pdf

Website files are often kept under /var/www, which is two directories above the root if the website is hosted on a Linux server. The following can be used by the attacker as the file name to exploit this:

../../etc/passwdIf the programme does not sanitise inputs, it will utilise the attacker’s string in a system call, change to the root user, and then give the attacker access to the /etc/ directory. The attacker is then able to access the password-protected file.

A similar attack can be performed on a Windows system using the string \..

Cookies frequently use web server directories to load the necessary files for a website. As a result, the website is vulnerable to a directory traversal attack. Take a cookie, for instance, that loads a fresh website design template by accessing a file:

<?php
$design = 'new-design.php';
if (isset($_COOKIE['DESIGN'])) {
$template = $_COOKIE['DESIGN'];
}
include("../resources/" . $design);
?>

In this scenario, the name of the file is stored in the DESIGN cookie and appended to a path. Because there is no validation of the $design variable an attacker can send a GET HTTP request that modifies the cookie value to DESIGN=../../etc/passwd

The web server would then perform the following system call, loading the passwd file instead of the design template.

include("../skins/../../etc/passwd");

Thank you for Reading This content.I hope you got some Knowledge from this post.Grow your Knowledge with medium.