A Guide to Directory Traversal Vulnerability in 2023
A path traversal attack, also called directory traversal, is an attempt to access files and directories that are stored outside the designated web root folder. This can be done by manipulating variables that reference files using sequences like “../” or by using absolute file paths. By doing this, attackers may be able to access sensitive files such as application source code or system configuration files. However, it is important to note that the attacker’s access to files is restricted by the operating system’s access control measures.
In most cases the URL take a file name parameter and returns the content of the specified files.
On Windows, both ../
and ..\\
are valid directory traversal sequences, and an equivalent attack to retrieve a standard operating system file would be:
IF there is any defense against path traversal attacks or an application strip or blocks the directory traversal then we can also use the absolute path from the file system root likewise filename=/etc/passwd.
You might be able to use nested traversal sequences, such as ....//
or ....\\/
, which will revert to simple traversal sequences when the inner sequence is stripped.
Example of usage :
….//….//….//etc/passwd
or
….\/….\/….\/etc/passwd
Sometimes, such as in a URL path or filename parameter of multipart/form-data request, and web servers may strip any directory traversal . We can bypass his by the URL encoding or even double url encoding. like-the ../
characters, resulting in %2e%2e%2f
or %252e%252e%252f
respectively. Various non-standard encodings, such as ..%c0%af
or ..%ef%bc%8f
, may also do the trick. Here we are gonna use the burp intruder and the pre payload list in the burp and might it will do the trick.
Encoding and double encoding:
%2e%2e%2f
represents../
%2e%2e/
represents../
..%2f
represents../
%2e%2e%5c
represents..\
%2e%2e\
represents..\
..%5c
represents..\
%252e%252e%255c
represents..\
..%255c
represents..\
Percent encoding (aka URL encoding)
Note that web containers perform one level of decoding on percent encoded values from forms and URLs.
..%c0%af
represents../
..%c1%9c
represents..\
An application requires that the user-supplied filename must start with the expected base folder, such as /var/www/images
, then it might be possible to include the required base folder followed by suitable traversal sequences.
Basically we can use the payload like: /var/www/images/../../../etc/passwd
Also if an application requires that the user supplied file name must ends with expected extension like .png then we can use the payload like.
filename=../../../etc/passwd%00.png
OR
../../../etc/passwd%00.jpg
Each operating system has a different path separator.
Unix/Linux
- Root Directory: “/”
- Directory Separator: “/”
Windows
- Root Directory: “<drive letter>:\”
- Directory Separator: “\”

Using Cookies for Directory Traversal
For example, consider a cookie that accesses a file to load a new design template for a website:
<?php
$design = 'new-design.php';
if (isset($_COOKIE['DESIGN'])) {
$template = $_COOKIE['DESIGN'];
}
include("../resources/" . $design);
?>
Here the file is stored in the DESIGN cookie and appended to a path. As there is no validation, then the attacker can send a GET HTTP request that modifies the cookie value to Design=../../etc/passwd.
The web server would then perform the following system call, loading the passwd
file instead of the design template.
include("../skins/../../etc/passwd");
The default root folder for a web server in the Linux file system is /var/www/html, where websites are deployed. Another significant location is /etc/passwd, which maintains a record of all authorized users who can access the system. The file path “/var/www/html/../../../etc/passwd” can be used to access sensitive information on a server by going through different directories. This is a potential security risk for the server since it can be accessed by malicious users or hackers.
Now lets Talk about “How to Bypass the DEFENSE FOR DIRECTORY TRAVERSAL”
- Using URL encoding-The majority of filters are designed to detect path traversal sequences in parameters. These filters are often referred to as lazy filters. If these filters detect any dots or slashes in the input, they will either reject it or sanitize it, which ultimately leads to our mission not being successful. In order to get around the lazy filter, we use URL encodings to encode all the dots and slashes in our input. These filters typically accept these encoded inputs, so we are able to successfully bypass them.

- USING NESTED TRAVERSAL SEQUENCES: You might be able to use nested traversal sequences, such as
....//
or....\\/
, which will revert to simple traversal sequences when the inner sequence is stripped.- Example of usage :
- ….//….//….//etc/passwd
- or
- ….\/….\/….\/etc/passwd
HOW TO DETECT +EXPLOIT
- Can you find request parameters which can potentially be used for file-related operations? For example:
https://mysite.com/getUserProfile.jsp?item=abcd.htm
- Can you detect any unusual file extensions? Such as:
https://mysite.com/index.jsp?file=content
- Do you see any interesting variable names? For example:
https://mysite.com/main.php?home=index.htm
- Be cautious of situations where a request parameter resembles a file or folder name, such as include=main.inc or template=/en/sidebar. Functions that are expected to require accessing data from a server’s file system, such as showing images or office documents.
- Search for error messages or unusual events that are noteworthy, as well as situations where user-provided data is being used in file APIs or as inputs for operating system commands.
- Discovering a Path Traversal vulnerability is relatively simple, as long as one can carry out the following actions.
- List the functions that involve inclusion and then evaluate them.
- How can you list the inclusion function? The answer is simple – just ask yourself this question. Are there any inclusion functions or file-related parameters in the URL or request body?
- Can you identify any unusual file extensions in the URL or request body?
- Modify the parameter’s value to insert an arbitrary subdirectory and a single traversal sequence.
- For example: If the application submits this parameter:file=foo/file1.txt
- try submitting:file=foo/bar/../file1.txt
- If the function you are attacking provides write access to a file, attempt to write two files, one that should be writable by any user, and one that should not be writable even by root or Administrator. For platforms, example, on Windows platforms try this:
- ../../../../../../../../../../../../writetest.txt
- ../../../../../../../../../../../../windows/system32/config/sam
- On UNIX-based platforms, files that root may not write are version dependent, but attempting to overwrite a directory with a file should always fail, so you can try this:
- ../../../../../../../../../../../../tmp/writetest.txt
- ../../../../../../../../../../../../tmp
- To more effectively search for flaws, it is recommended to submit a significant amount of traversal sequences. This is because the directory where data is added may be located far down in the filesystem, and submitting many sequences can prevent incorrect negative results.
- The Windows platform allows the use of both forward slashes and backslashes as directory separators, while UNIX-based platforms only allow forward slashes.
- Some web applications may block one version of an operating system but not the other. Even if you know the webserver is using a UNIX operating system, the application may still be using a Windows-based component in the background. Therefore, it is recommended to test both versions when searching for traversal vulnerabilities.
We don’t know anyone who can say “No” to this File Inclusions and Directory Traversal Difference
- Local File Inclusion (LFI): LFI is a vulnerability that occurs when an application includes a file based on user input, without proper validation or sanitization. This vulnerability allows an attacker to include arbitrary files from the local file system of the server. The attacker can manipulate the input to include sensitive files, such as configuration files, system files, or even execute malicious code.
For example, consider a web application that includes ahe file based on a user-provided parameter, like http://example.com/index.php?page=userInput
. If the application does not properly validate and sanitize the userInput
parameter, an attacker can provide a path to a file on the server, such as ../../../../etc/passwd
, and the application will include the contents of that file in the response.
The main goal of LFI attacks is to read sensitive files or execute arbitrary code within the context of the vulnerable application.Basically we can here read the files and excecute them and manipulate them to get full access.
- Directory Traversal (Path Traversal): Directory Traversal is a vulnerability that allows an attacker to access files or directories outside the intended scope of the web application. It occurs when the application does not properly validate and restrict user input that represents a file path or directory name.
An attacker can manipulate the input to navigate through the file system directories and access files that are meant to be restricted. This can lead to the exposure of sensitive information or even the execution of arbitrary files.Here we can only read the files.
For instance, consider a web application that serves files based on a user-provided parameter, like http://example.com/files/?file=userInput
. If the application does not validate and sanitize the userInput
parameter, an attacker can provide a path such as ../../../../etc/passwd
and retrieve the contents of that file.
The main goal of Directory Traversal attacks is to access files or directories that are outside the intended scope of the web application.
In short, LFI is a vulnerability that allows the inclusion of arbitrary files from the local file system, while Directory Traversal allows an attacker to navigate outside the intended file/directory scope to access restricted files. Both vulnerabilities can have severe consequences if not properly mitigated.

dotdotpwn-The Directory Traversal Fuzzer
It is an intelligent fuzzer which is used to discover traversal directory vulnerabilities.DotDotPwn is a clever tool that helps attackers find possible vulnerabilities related to directory traversal in a specific service. It is effective in detecting flaws in web server protocols such as TFTP, HTTP, and FTP. This tool is especially helpful during penetration testing of web-based applications. DotDotPwn is a tool that comes pre-installed in Kali Linux because it is a part of the package.
DotDotPwn is a versatile fuzzing tool that can apply advanced intelligence during fuzzing operations. It is commonly used by hackers to target web platforms such as ERPs and CMSs. One of its notable features is the ability to run a protocol-independent module, which enables users to deliver a payload to a host via a specified port. The STDOUT module is useful for scripting operations and can automate fuzzing operations, which helps identify vulnerabilities that can be targeted in an attack. DotDotPwn is a tool that can identify mistakes caused by incorrect data validation, inaccurate parameters, or erroneous data. This type of information can assist attackers in determining the appropriate attack payload to use against their target. Due to the tool’s versatility, it can offer multiple attack vectors that can be exploited during an attack.
Installation
Cloning the repo:
$ git clone https://github.com/wireghoul/dotdotpwn.git
Navigate it to the working directory:
$ cd dotdotpwn
$ ./dotdotpwn.pl
To install missing modules, you can use the following command as root:
$ cpan
cpan> install
Usage:
For detailed examples.

Let’s Talk About The Prevention!!
- Input Validation and Sanitization: Always validate and sanitize user input that represents file paths or directory names. Ensure that the input conforms to the expected format and does not contain any unauthorized characters or sequences. Apply strict filters and restrictions to prevent traversal attempts.
- Whitelisting Approach: Implement a whitelist-based approach to define the allowed files and directories that can be accessed by the application. Create a list of acceptable file paths or directory names and validate user input against this whitelist. Reject any input that falls outside the defined scope.
- Absolute File Paths: Instead of relying on relative file paths, use absolute file paths when accessing files or directories within the application. By using absolute paths, you eliminate the risk of traversal attacks as the file access is limited to the specific location.
- Secure File Access Mechanisms: Utilize secure file access mechanisms provided by the programming language or framework you are using. Avoid using direct file system calls and instead leverage built-in functions or libraries that handle file operations securely.
- Restrict File System Permissions: Set appropriate permissions and access controls on files and directories to restrict unauthorized access. Ensure that the web application has limited access rights and is unable to traverse outside its intended scope.
- Secure Development Practices: Follow secure coding practices, such as avoiding the use of user input directly in file system operations without proper validation. Implement secure coding guidelines and conduct regular code reviews to identify and address any potential security vulnerabilities.
- Security Testing: Perform comprehensive security testing, including penetration testing and vulnerability scanning, to identify any potential Directory Traversal vulnerabilities. Use specialized tools or security services to automate the detection of such vulnerabilities and validate the effectiveness of your mitigation measures.
- Keep Software Updated: Regularly update your web application framework, libraries, and components to ensure that you have the latest security patches and fixes. Vulnerabilities in the underlying software stack can sometimes be exploited to bypass security measures and carry out traversal attacks.
- After validating the supplied input, the application should append the input to the base directory and use a platform filesystem API to canonicalize the path. It should verify that the canonicalized path starts with the expected base directory.
- Below is an example of some simple Java code to validate the canonical path of a file based on user input.
- File = new File(BASE_DIRECTORY, userInput); if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) { // process file }
Refrences:-
- https://github.com/wireghoul/dotdotpwn/blob/master/EXAMPLES.txt
- https://github.com/wireghoul/dotdotpwn
- https://asfiyashaikh.medium.com/file-path-traversal-and-file-inclusions-7c567da9e226
- https://infosecwriteups.com/finding-path-traversal-vulnerability-e2506d390569
- https://www.hackingloops.com/how-to-use-dotdotpwn/
- https://medium.com/@Steiner254/directory-path-traversal-288a6188076
- https://portswigger.net/web-security/file-path-traversal
- https://systemweakness.com/how-to-exploit-directory-traversal-vulnerabilities-176eeb7f2655
In the Next blog, we will learn about Web sockets and practice the labs!!
Read our Previous Blogs.
If you enjoyed this blog post, share it with your friends and colleagues!!
Recent Comments