Attack Directory Traversal
Attack Directory Traversal
Abstract
1
Contents
1 Introduction to Directory Traversal 3
5 References 25
2
1 Introduction to Directory Traversal
Directory Traversal, also known as file path traversal, is a serious
web security vulnerability that enables attackers to read files on a
server that is running a web application. This can include sensitive
files such as application code and data, as well as credentials for back-
end systems and operating system files. In some cases, attackers may
also be able to modify files on the server, which can lead to a complete
takeover of the system.
3
Figure 1: Directory Traversal
4
2.1 Unauthorized Access to Sensitive Data
One of the most significant risks associated with directory traver-
sal attacks is the unauthorized access to sensitive data. This can
include personal information, financial records, or proprietary intel-
lectual property. By exploiting directory traversal vulnerabilities, at-
tackers can gain access to files and directories that are not meant to be
publicly accessible, potentially leading to data breaches and significant
legal and financial consequences for the affected organization.
5
execute arbitrary code, manipulate data, or perform other malicious
actions that would otherwise be restricted.
6
3 How to Exploit Directory Traversal Vul-
nerabilities
To better understand web application exploitation, we will be using
a lab environment that has already been set up. This lab includes
several PHP-based web applications, and you can access the relevant
environment through the references section. As shown in the figure
below, there is currently a PHP-based web application running on
port 8091 within the lab environment.
7
Our initial inspection of the webpage reveals that clicking on images
produces a URL in the format “loadimage.php?file name=image.png”.
8
We then open Burpsuite and enable interception in the Proxy tab.
Next, we click on an image, and as shown in the figure below, Burp
intercepts the corresponding request. From here, we proceed to inject
our payloads into the “file name” parameter in the GET request.
9
When attempting to navigate to the root directory, we commonly
employ the ”../” notation, which allows us to move up one directory
level. The exact number of directories we need to climb is not always
known, hence the advantage of the ”../” notation, which lets us ascend
one directory at a time until we reach the root directory.
After sending request with our crafted payload, we’ve successfully ac-
cessed /etc/passwd as you can see.
10
Figure 5: Succesful Exploitation
11
Moving forward, we will explore another web application in our lab.
It appears quite similar to the previous one and is also developed with
PHP. However, it seems to handle file requests differently.
12
Figure 7: Intercepted Request
13
Upon closer inspection of the application, we notice that it iden-
tifies any file name containing ’..’ and subsequently returns a ’Hack
detected’ message. While we could consider using URL encoding as a
standard approach, there is another crucial method we should explore
first. Up until now, we have attempted to read /etc/passwd using rel-
ative paths. It is now a good time to try absolute path as input.
As shown in the figure below, we filled in the file name field with
’/etc/passwd’ and successfully read the file.
14
on a web server. To prevent these types of attacks, developers should
follow best practices when designing and implementing their web appli-
cations. It is recommended that application functionality is designed
in a way that avoids passing user-controllable data to filesystem op-
erations. One approach is to reference known files using an index
number instead of their name and to save user-supplied file content
using application-generated filenames. However, in situations where
passing user-controllable data to a filesystem operation is unavoidable,
it is crucial to follow all the steps below:
^[a-zA-Z0-9_\-]+$
Key points:
• Whitelist approach
15
4.1.2 Canonicalization
Key points:
• Convert file paths to standard representation
• Compare the canonical path with the raw path for potential dis-
crepancies
16
4.1.3 Limit File System Access
Key points:
Key points:
17
• Use chroot command, Docker containers, or virtual machines
Key points:
• Use generic error messages
18
• Rewrite URLs to prevent direct access to specific file types. In
Apache, you can use the mod rewrite module to create rewrite
rules.
For other web servers, such as Nginx or Microsoft IIS, similar con-
figurations can be applied to achieve comparable levels of protection.
Key points:
Key points:
19
By following these best practices, you can significantly reduce the
risk of a successful path traversal attack and protect your application
and its sensitive data. Remember, security is an ongoing process; stay
vigilant and continually assess your application’s security posture to
ensure the highest level of protection.
20
4.2 Attempt to Mitigate Exploited Vulnerabilities
Let’s begin with our first scenario. In the provided source code for the
file reading operation, you can see that no precautions have been taken
to prevent security vulnerabilities. As a result, we could easily access
sensitive files like /etc/passwd using relative paths with dot-dot-slash
(../) approach.
21
Figure 11: Scenario 2- sanitizeFilePath function added
22
As we proceed to the second scenario, let’s remember that we pre-
viously exploited it by accessing the /etc/passwd file using an absolute
path. Upon examining the source code, it becomes apparent that the
code only checks for the presence of the ”../” sequence in the file in-
put. The intention is to prevent path traversal attacks by stopping the
script execution with a ”Hack detected” message if it detects the ”..”
sequence.
• The code solely checks for the ”..” sequence, but creative attack-
ers might use different encoding methods or techniques to bypass
this basic check.
• The input file name is neither sanitized nor validated in any other
way.
23
example demonstrates how to modify the code using a whitelist that
contains the eight image files we want to allow:
Now, let’s attempt to exploit this level using the same payload we
used in the how to exploit section. As you can see, the attacker’s
provided input is not on the whitelist, so our function detects the
discrepancy and returns an error. I would like to reiterate that these
precautions are quite basic, and in real-world scenarios, a multi-layered
security approach should be implemented for optimal protection.
24
Figure 15: Scenario 2- Initial Exploit Method Failed
5 References
• https://github.com/0136misa/path-traversal-vulnerabilities
• https://www.invicti.com/learn/directory-traversal-path-traversal/
• https://portswigger.net/web-security/file-path-traversal
• https://www.acunetix.com/websitesecurity/directory-traversal/
• https://www.synopsys.com/glossary/what-is-path-traversal.
html
• https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_
Cheat_Sheet.html
• https://owasp.org/www-community/attacks/Path_Traversal
• https://wiki.owasp.org/index.php/File_System#Path_traversal
25