In this blog post, we will try to understand what a directory traversal attack is in simple terms and how does it actually works, what causes directory traversal attacks and at the end I will wrap up by showing a real-word demonstration and mitigations for the same. Let’s get started…

Directory Traversal

Directory Traversal /Path Traversal (aka Dot-Dot Slash attack) is a web application vulnerability, that allows an attacker / malicious user to read sensitive files on the OS where the web application is running. To achieve this the attacker abuses the parameter present into the URL via GET or the POST body. Mainly, the attacker will try to locate the files present into the root directory of the OS (either Linux or Windows).

Example: Directory traversal attacks may happen in any programming language which is used into the backend of a web application. In this example, we will make use of PHP — a well known programming language used at the backend of the web applications. So, PHP itself has a function named as file_get_contents whose job is to used to read the entire contents of a file into a string.

So, say for instance, there’s a URL present as https://example.com/file.php?cv=resume.pdf

Now, what will happen is, when this URL gets executed the file.php code executes in the web server and the web server then goes into the file system of the OS and searches for the file named as resume.pdf into /var/www/html/resume.pdf. If the web server finds it, it simply displays it back onto the screen of the end user and the user can see their resume! Seems simple right ?

Now, here is where a malicious user runs their brain and instead of fetching resume.pdf file, they manipulate the path to ../ to check whether they can move a directory UP or not.

If the attacker sees of an error or if something suspicious is detected which may lead to path traversal, the attacker will further dig deep into the file system. So, say for example, when the user executed ../ in the cv= parameter, they got to know the contents (files and directories) of that particular directory, visible onto his web page. The attacker may dig deep using the payload ../../../../ until he finds and reads off the sensitive files of the OS such as /etc/passwd and /etc/shadow which contains user information and password hashes on a Linux OS respectively.

As you can see in the screenshot above, the attacker has passed a directory traversal payload ../../../../etc/passwd into the file= parameter. Now, instead of fetching the resume file for the user, the file parameter will get executed into get.php file and the contents of OS level files such as /etc/passwd will be listed onto the screen of the end user, hence exposing very sensitive information.

Note: The ../ may vary depending on how deep is the web app located into the OS file system. So if it’s /var/www/html then the malicious user will just go 3 directories upwards like: ../../../etc/passwd to grab the contents of passwd file.

Also, it is necessary to note that it’s not always the case that the attacker will try to extract or read the contents of passwd or shadow file, he may have other intentions such as reading and then leaking the source code files, gather other sensitive information from the system, etc.

Real world scenario:

While performing a pen-test on one of the web applications, directory listing was found to be enabled which resulted into the listing of directories and files present onto the OS. However, OS level files were not found.

Below is another screenshot for a path traversal where web application’s backend source code was leaking along with other PHP files.

Remediation

• Allow only safe filenames → Use a whitelist of expected files instead of taking full paths from the user.
• Block dangerous patterns → Reject ../, %2e%2e, ..\\, or anything with slashes/absolute paths.
• Keep files in a safe folder → Restrict access to one directory (like uploads/) and make sure user input can’t escape it.
• Use safe path functions → Use path.join() or Path.resolve() and check the final path stays inside the allowed folder.
• Run app with limited access → The app user should not have permissions to read sensitive system files.

Would like to hear your comments. Thanks!