Directory traversal (also called Path traversal) is an exploit which lets attackers access restricted directories, execute commands and view data outside the normal Web server directory where the application content is stored.
By manipulating files with “dot-dot-slash (
../)” sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on the filesystem; including application source code, configuration, and other critical system files.
Enumerate input vectors.
Analyse input validation functions.
List all application components that can accept user input, such as
GET calls, HTML forms, and file uploads. Check for:
Request parameters which can potentially be used for file-related operations, such as
Unusual file extensions, like
Interesting variable names, for example
Try inserting relative paths into files existing on the web server, for example:
Many applications that place user input have some kind of protection against path traversal attacks:
Applications can strip or block directory traversal sequences from the user-supplied filename => try an absolute path, nested traversal, and url encoding (in a
Some applications validate start of path => include the required base folder followed by suitable traversal sequences.
It can be that the filename value must end with an expected file extension => try a null byte like
%00before inserting a valid extension.
Absolute path from the filesystem root to directly reference a file without using any traversal sequences:
Nested traversal sequences which will revert to simple traversal sequences when the inner sequence is stripped:
Check whether a system is vulnerable to certain tricks like a
../ removal that uses percent-encoded values:
url encoding: %2e%2e%2f double url encoding: %252e%252e%252f
Null byte bypass
With a directory traversal, it may be possible to read arbitrary files on the server that is running the application. This might include application code and data, credentials for back-end systems, and sensitive operating system files. In some cases, it may be possible to write to arbitrary files on the server, modifying application data or behaviour, and ultimately taking full control of the server.
Portswigger lab writeups
File path traversal, traversal sequences blocked with absolute path bypass
File path traversal, traversal sequences stripped non-recursively
File path traversal, traversal sequences stripped with superfluous URL-decode
File path traversal, validation of file extension with null byte bypass
Avoid relying on user-supplied input when dealing with filesystem APIs. Oh well, back to the drawing board, because this might require rewriting a major part of the application.
Prevent the user-supplied directory from being higher up on the filesystem than the directory used to serve static content.
Sanitise user-supplied data and get rid of unexpected inputs, for example by maintaining a set of allowed filesystem paths and comparing user input against that set or by allowing only alphanumeric characters and rejecting inputs that contain other characters.
If that is not possible, consider disallowing dangerous characters explicitly.
Sanitisation of user input is a never-ending story and requires constant verification against newly discovered ways to bypass known protection methods. It may be better to use a well-maintained open-source library for it. Check these open source libraries with vulnerability scanners to find the best candidates.
Another option is to build the application with web frameworks, which have built-in support for serving static content.
Use secure coding practices at every stage of the development and operations pipeline:
Static application security testing (SAST) reviews the source code of the application when it is not running. SAST checks try to identify evidence of known insecure practices and vulnerabilities. SAST solutions employ white-box techniques.
Dynamic application security testing (DAST) communicates with the application through its front-end in order to identify security vulnerabilities. A DAST tool does not need any access to source code. It simulates real attacks using a black-box strategy. Security checks are done while executing or running the application or code under review. It can also involve fuzzing to uncover directory traversal vulnerabilities.