Directory Traversal is a vulnerability that occurs when user-manipulable input is passed to the file system of a web application server and used in an insecure manner. An attacker can use path navigation characters such as dot.slash (../) or dot..backslash (..\) in manipulable parameters to access restricted parent directories beyond the web root directory (the top-level directory of the web application). This allows you to view directories and files that are sensitive or should not be viewed.
How Directory Traversal Vulnerability Works
Let’s assume we have http://example.com, which dynamically returns a web page using a GET parameter called “filename” as follows.
http://example.com?filename=intro.php
The web application that receives the above request will search the web root directory of the server file system for the file name specified in the “filename” parameter and display the contents of that file if it exists. The intro.php file is assumed to exist in the web root directory. For reference, the default web root directory is as follows depending on the running web server program.
- IIS – C:\inetpub\wwwroot\
- Apache – /var/www/html/ or /var/www/ etc.
- NginX – /var/www/html/
Normal file request and response process
Unfortunately, example.com is vulnerable to directory traversal attacks due to developer error. The “filename” parameter allows an attacker to send a randomly crafted attack string and access directories that the attacker does not have permission to access.
To achieve this, attackers use directory traversal sequences such as the dot.slash (../) in the attack string to move to the parent directory of the current directory. Please note that Windows, unlike Linux/Unix, can use a backslash (\) as a directory separator.
| division | Linux/Unix | window |
| current route | . (Dot, dot) | . (Dot, dot) |
| parent path | .. (Dot Dot, dot dot) | .. (Dot Dot, dot dot) |
| directory | / (Slash, slash) | / (Slash, slash) or\ (Back-slash, backslash) |
If you use a directory traversal sequence enough times in succession to move up to the system’s root directory (in the form ../../../../../../), you will leave the web root directory and finally reach the server. You will access the root directory of . At this time, the user account on the server used by the attacker is the user account (www-data, etc.) that runs a web server program such as Apache. In other words, an attacker can access the contents and files of directories that have permission for the user account running the web server and uses the following manipulated command to read the /etc/passwd file where user information is stored in the Linux operating system. You can use URL.
http://example.com?filename= ../../../../etc/passwd
Sensitive information leaked through directory traversal attack
Impact of directory traversal vulnerabilities
The impact of directory traversal vulnerabilities is affected by the ACL (Access Control List) applied to the user account of the web server such as Apache that runs the web application. In general, potential impacts include:
- The server’s directories and files can be accessed, making the server’s directory structure public.
- By accessing the configuration file of Apache or other services running on the server, important information is leaked and the attacker can obtain additional information needed for the attack or expand the attack to other services.
- By accessing the bash_history file, you can find out sensitive information such as database connection information from the list of commands executed by the user.
- Although it is a limited case, if the file upload function of a web application is vulnerable to a directory traversal attack, an attacker can upload a file (web shell) to an arbitrary path on the server by manipulating the file upload path, and the web application is exposed to remote code execution. It’s possible.
Preventing directory traversal vulnerabilities
The best way to prevent directory traversal vulnerabilities is to not allow requests for files or directories to be directed to the server’s file system. However, if it is unavoidable to allow it, the following methods must be applied in combination to make attacks difficult.
Apply input validation
When a request for a file or directory is allowed, it is verified whether a directory traversal sequence such as a parent directory (../) or a home directory (~/) or a NULL byte exists in the requested file name and is removed. When removing directory traversal sequences, they must be completely removed recursively, as flaws in the removal logic could allow an attacker to use slightly modified attack strings (such as ….//). Additionally, attack strings may be URL-encoded or transformed into other encoding formats, so verify attack strings in all possible encodings.
File reference through index
Rather than requesting a file path or file name directly in a request, the request is implemented by mapping a specific index and file so that the request is made through the index. For example, manage the some-file.html file with a separate index of 3, and use the format example.com?fileidx=3 when making requests. Requests with invalid indexes are rejected.
example.com?filename=some-file.html (X)
example.com?fileidx=3 (O)
Enforce least privilege
Minimize permissions so that the user account running the web application (such as www-data) cannot access unnecessary system directories or files.
server patch
Always keep your web server, operating system, etc. up to date.
In addition, strengthen security through additional protection measures such as using a web firewall (WAF).
Path Traversal Test Method
Step 1. Explore requests associated with the file system
Find all requests that process files in the target web application. The following are the areas you need to focus on and check.
1. File upload/download functions must be checked.
2. Check whether there is a request that dynamically loads settings such as a web page, style sheet, or template through GET parameters, URL path or POST body data, or request headers (Cookie, etc.).
- GET parameters
http://www.target.com/view.php? file=some-file.html
- URL path
http://www.target.com/download/some-file.pdf
- POST Body data
POST /getcontents HTTP/1.1
Host: www.target.com
...omitted...
filename=some-file.html
- Dynamic creation of templates via Cookie request header
Cookie: bbc_id=bcae2ff6d760458ebbee5b48df22150c; bbc_asx=1245431 ; bbc_template=some-template
3. Find requests that use a file name or directory name in the request. For example, this applies to importing PDF files such as image files or reports and loading them into a web browser.
Step 2. Check whether it is vulnerable to directory traversal attacks
If you find a suspicious request, use a directory traversal sequence to see if the /etc/passwd or win.ini files can be read.
- Linux/Unix series (/etc/passwd)
http://www.target.com/view.php? file=../../../../../etc/passwd
- Windows (win.ini)
http://www.target.com/view.php? file=../../../../../windows/win.ini
http://www.target.com/view.php? file=..\..\..\..\..\windows\win.ini
If the contents of the file are displayed through a web browser, it is vulnerable to directory traversal attacks. However, if the developer checks the validity of data received from the user to prevent directory traversal attacks, the above basic method may be blocked. In this case, you should try to bypass the filter.
Step 3. Bypass validation
Filters implemented in an insecure manner can be bypassed by identifying flaws in the verification logic.
If a filter is applied to remove dot..slash (../) and dot..backslash (..\), but the filter does not remove them recursively, try bypassing them using the following attack string.
....//
..././
....\\
...\.\
....\/
..../\
The above attack string is a valid directory traversal sequence even after passing the filter, so it is still possible to move to the parent directory. (The shaded portion is the portion removed by the filter.)
. . ../ / -----Filter-----> ../
. ../ ./ -----Filter-----> ../
.. ..\ \ -----Filter-----> ..\
. ..\ .\ -----Filter-----> ..\
.. ..\ / -----Filter-----> ../
.. ../ \ --- --Filter-----> ..\
Alternatively, the bypass may be possible by converting each character that makes up the directory traversal sequence into a different encoding format and combining them into an attack string.
| message | URL encoding | 16 bitUnicode encoding |
| . (dot) | %2e | %u002e |
| / (slash) | %2f | %u2215 |
| \ (backslash) | %5c | %u2216 |
Different encodings of directory traversal sequence characters
The following are directory traversal sequences assembled using the above encoding format.
- URL encoding
%2e%2e/%2e%2e%2f%252e%252e%252f%2e%2e\%2e%2e%5c%252e%252e%255c
- 16-bit Unicode encoding
%u002e%u002e/
%u002e%u002e%u2215
%u002e%u002e\
%u002e%u002e%u2216
Visit PayloadAllTheThings to see various payloads for bypassing filters.
That’s all. Have a nice day, everyone!
❤️ If you liked the article, like and subscribe to my channel “Codelivly”.
👍 If you have any questions or if I would like to discuss the described hacking tools in more detail, then write in the comments. Your opinion is very important to me!
