Path Traversal or as it is otherwise known, Directory Traversal, refers to an attack through which an attacker may trick a web application into reading and subsequently divulging the contents of files outside of the document root directory of the application or the web server. Path/Directory Traversal attacks typically manipulate web application inputs by using the dot-dot-slash (
../) sequences, or similar variations (such as
.. in Microsoft Windows) to access server file system folders that are higher in the hierarchy than the web root folder.
Typically, Path Traversal attacks are used to gain access to sensitive information stored within arbitrary files in other areas of a web application or in other parts of the filesystem that the web server can read. Since files containing sensitive information may contain secrets such as passwords, access tokens, or backups, a successful Path Traversal attack may allow an attacker to take their reconnaissance further or exploit other application security vulnerabilities.
Path Traversal may not be as common as SQL Injection or Cross-site Scripting and is not considered as dangerous, but it still poses a major risk to web application security. This vulnerability is not directly included in the current OWASP top ten list but it may be interpreted as being part of category A5 — Broken Access Control.
Path Traversal in Practice
The following is an example source code in PHP that is vulnerable to Path Traversal.
/** * Get the filename from a GET input * Example - http://example.com/?file=filename.php */ $file = $_GET['file']; /** * Unsafely include the file * Example: filename.php */ file_get_contents('directory/' . $file);
In the above example, an attacker could make the following request to trick the application into divulging the contents of the /etc/passwd system file, which contains a list of users on the server:
Similarly, an attacker may leverage a Path Traversal vulnerability to gain access to application code, credentials, password files, ini files, logs and other sensitive information that may help advance an attack.
Path Traversal is certainly not limited to accessing the /etc/passwd file. Since everything in UNIX/Linux-based systems is a file, an attacker can gain a wealth of information about a vulnerable application just by reading the right files on a system. The following are just a couple of examples of how Path Traversal can be used to gain information about the system the vulnerable application is running on.
The /proc/version file contains the version of the Linux kernel running on the system. This information can be used by an attacker to determine the operating system version and determine if any security updated could be missing.
The /proc/mounts file provides a list of file systems that are mounted and can be used by an attacker to learn where potentially interesting and sensitive files may be located.
The /proc/net/arp file lists the system’s Address Resolution Protocol (ARP) table, which could provide an easy way for an attacker to discover other connected systems.
The /proc/net/tcp and /proc/net/udp files can provide an attacker with a list of active connections. This information can be used to determine, which ports are open for listening on the server and therefore, which services the server is likely running.
Preventing Path Traversal Vulnerabilities
The best way to eliminate Path Traversal vulnerabilities is to avoid reading files dynamically based on user input. If this is not possible, the application should employ strong input validation by maintaining a whitelist of files that can be included in order to limit the attacker’s control over what gets included. Typical web application security mechanisms such as filtering based on file path elements, file extensions and such prove to be inefficient in this case because attackers can use special characters and character sequences to trick the filter.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by acunetix. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/vI_PgjFQJCk/