If an application uses client-given parameters to build the path to a file, and proper input validation and access permissions checks are done, an attacker can change the name of the file and/or prepend a path to the filename in order to retrieve a different file. This is called path traversal or directory traversal. Most web servers have been locked down to prevent this type of attack, but applications still need to validate inputs when directly referencing files.

Users should be restricted to navigate only the web root directory and should not be able to access anything above the web root. A malicious user will look for direct links to files out of the web root—the most attractive being the operating system root directory.

The basic path traversal attack uses the ../ sequence to modify the resource request through the URL. The ../ expression is used in operating systems to move up one directory. The attacker has to guess the number of directories necessary to move up and outside the web root, which can be done easily using trial and error. If the attacker wants to move up three directories, then they must use ../../../.

Let's use DVWA to consider an example: we will use the File Inclusion exercise to demonstrate a path traversal. When the page loads, you will notice that the URL has a page parameter with the include.php value, which clearly looks as if it is loading a file by its name:

If you visit the URL, you can see that the page that is loading the include.php file is two levels below the application's root directory (/vulnerabilities/fi/) and three levels below the server's root (dvwa/vulnerabilities/fi/). If you replace the filename with ../../index.php, you will be going up two levels and then showing the DVWA's home page:

You can try to escape the web server root to reach files in the operating system. By default, Apache web server's root on GNU/Linux is at /var/www/html. If you add three more levels to the previous input, you will be making a reference to the operating system's root. By setting the page parameter to ../../../../../etc/passwd, you will be able to read the file containing the user's information on the underlying operating system:

The /etc/passwd path is a sure bet when testing for path traversal in Unix-based systems, as it is always there and is readable by everyone. If you are testing a Windows server, you may want to try the following:

../../../../../autoexec.bat
../../../../../boot.ini
../../../../../windows/win.ini