Directory Traversal Mitigation: How to Prevent Attacks
In a directory traversal attack, a malicious user utilizes directory traversal attempts to gain access to files on the server they shouldn’t have access to. To perform a directory traversal attack, an attacker attempts to manipulate and submit different information to the target, via a URL address line or another input method.
However, a directory traversal attack doesn’t only have to result in access to otherwise forbidden files or directories. The same vulnerability can be used to upload malicious files to a web server too, making early detection and remediation of directory traversal vulnerabilities a crucial task.
Read the following article first if you want to learn more about directory traversal in general. This article is going to focus on directory traversal mitigation.
In this article:
- How to mitigate directory traversal attacks?
- How to manually test for directory traversal vulnerabilities
- Step 1: Search for file names in request parameters
- Step 2: Monitor all filesystem interactions the application performs
- Step 3: Modify the parameter’s value
- Step 4: Try to bypass the application’s validation filters
- Step 5: Try to traverse out of the starting directory
- Step 6: Does the target application function provide read access to a file?
- Step 7: Does the target application function provide write access to a file?
- Step 8: Verify a traversal flaw with write access
- Automatically test for directory traversal vulnerabilities with Bright
How to mitigate directory traversal attacks?
One method for preventing directory traversal attacks is to avoid passing user-supplied input to filesystem APIs. Many functions that pass user-supplied input can be rewritten so they retain the same behavior, but in a much safer manner. If passing user-submitted content to filesystem APIs is unavoidable, ensure use of these two layers of defense:
- Validate user supplied input: Make sure the application always validates used-supplied input before processing it. The validation can be conducted by either comparing the user-submitted input to a whitelist of acceptable values, or by verifying the input contains only acceptable content (e.g. purely alphanumeric characters).
- You must implement a mechanism to ensure that the canonicalized path starts with the expected base directory: It is critical that your application validates that the base directory at the beginning of the canonicalized path is correct.
The source of a directory traversal vulnerability is often in the source code of the application, but it can also be in the web server itself. If that is the case, just mitigating the vulnerabilities in your source code won’t be enough. Make sure your web server is up-to-date, and is well maintained.
Don’t limit your efforts just to these tips, as web servers provide two security mechanisms that can help you with prevention of directory traversal attack, namely Access Control Lists and Root Directory.
How an ACL can help prevent directory traversal attacks
A filesystem ACL contains the information about user access privileges to a system object, a single file, or a file directory and informs the computer operating system about those privileges. An access control list is connected to every object by the object’s security property.
Once a user requests an object, the ACL is checked for a relevant entry and the operating system sees if the user has the right permissions for the requested operation.
The role of Root Directory in preventing directory traversal attacks
The root directory limits a user’s access to anything above their specific directory on a web server file system.
Here is an example that can help understand what a root directory does:
You have an application on IIS, and the default root directory is C:Inetpubwwwroot. The root directory will limit a user in accessing, for example, C:Windows. Still, this will not prevent the user from accessing C:Inetpubwwwrootnews or any other files or directories in the root directory.
The root directory will prevent a malicious user from accessing files like C:WINDOWS/system32/win.ini or /etc/passwd depending on the platform.
Here are some additional tips on how to stay safe from directory traversal attacks:
- File system calls and user-supplied input can be dangerous together, so avoid it when possible
- When you are templating or using language files, you should use indexes instead of the actual sections of the file name
- Prevent the user from supplying the whole path
- Validate the user-supplied input by comparing it to a whitelist
- Utilize chroot jails and access policies to control where files can be saved and retrieved
- If you must use user-supplied input in file operations, the input must be normalized before being used in files or APIs.
How to manually test for directory traversal vulnerabilities
You can detect directory traversal vulnerabilities by either using a manual or an automated approach. Let’s go over the steps you’ll need to take to manually test for directory traversal flaws:
Step 1: Search for file names in request parameters
Our first step is to find request parameters that contain a file name or the name of a directory. Look out for something like include=main.inc or template=/en/navbar.
Step 2 – Monitor all filesystem interactions the application performs
Are there error messages or instances of operating system commands and file APIs that contain user-submitted input as parameters?
Make sure you monitor all filesystem interactions the application performs.
Step 3 – Modify the parameter’s value
Upon finding what you are looking for, you can change the parameter’s value so you can add an arbitrary subdirectory and insert one traversal sequence.
Here is an example – Imagine that the application submits the following parameter: file=foo/file1.txt. If you submit something like file=foo/bar/../file1.txt and you receive the same response, then this might indicate a vulnerability in the application.
There is a chance your application is vulnerable if the behavior stays the same in both cases. To verify the application is vulnerable, traverse above the start directory and try to access different files.
Step 4 – Try to bypass the application’s validation filters
If the application response is different in those two cases, that could mean the application blocked the parameter, the parameter got stripped, or the traversal sequence got sanitized, resulting in an invalid file path.
Experiment with bypassing the validation filters in the application.
Step 5 – Try to traverse out of the starting directory
Is there any scenario in which you can submit traversal sequences without affecting the application’s behavior if you do not step above the starting directory? To access files on the server, try traversing out of the starting directory.
Step 6 – Does the target application function provide read access to a file?
If the application function allows read access to a file, you can try to access known files on the operating system. To do so, submit the following:
../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../windows/win.ini
The browser will show the content of the requested file if the attempt was successful.
Step 7 – Does the target application function provide write access to a file?
Does the function you’re targeting provide write access to a file? Try to write two files, where one file any user has write permissions, and another one where even the Administrator or root user doesn’t have write permissions.
Try this if on Windows platforms:
../../../../../../../../../../../../writetest.txt
../../../../../../../../../../../../windows/system32/config/sam
If you are on a UNIX-based platform, try for example this:
../../../../../../../../../../../../tmp/writetest.txt
../../../../../../../../../../../../tmp
An application that behaves differently in response to those two requests is probably vulnerable.
Step 8 Verify a traversal flaw with write access
To test a traversal flaw with write access, create a new file in the web server’s webroot. If you are able to retrieve this file with a browser, your application is vulnerable.
Automatically test for directory traversal vulnerabilities with Bright
Bright Security enables you to easily scan your webapps and APIs for hundreds of security vulnerabilities, including testing for Directory Traversal vulnerabilities by performing its Local File Inclusion tests.
Whether as a standalone scanner or integrated across your CI/CD so developers can own security testing, Bright automatically validates every finding, delivering no false-positive results with developer-friendly remediation guidelines to find and fix issues early and often.
Detect security vulnerabilities in your apps and APIs for FREE – register for a Bright account!
