Summary
“Path traversal attack prevention starts by understanding the path traversal vulnerability in detail, and how you can implement path traversal best practices in your environment. In this article, we answer the question “what is path traversal”, provide examples of this attack, and the use of application security in defense. Think of it like your path traversal cheat sheet! ”
A path traversal vulnerability, also known as a directory traversal, is a kind of vulnerability where attackers manipulate the variables that reference files, and can then access files and directories stored outside of the web root folder.
By manipulating ../ or “dot-dot-slash” sequences and variations using absolute file paths, attackers can access files and directories, including critical system files, password stores, and application source code. This kind of attack is sometimes known as a dot-dot-slash attack.
How Does A Path Traversal Vulnerability Work?
Organizations may be at risk of path traversal vulnerabilities if an application does not correctly sanitize or restrict user inputs for referencing file paths.
In many web applications, user input is the method with which file paths or filenames are referenced. In order to download or view documents, applications allow users to enter a filename, which is then pulled and served to the user by the server. Without adequate input validation, threat actors can use this approach to inject malicious file path sequences, navigating to parent directories or other files which are not meant to be provided or exposed.
In short, in a path traversal attack, the crafted input of an attacker tricks the application into retrieving files that are outside of the intended structure of the directory by using ../ or ..\ to traverse directories.
What are the Consequences of a Path Traversal Attack?
If successful, a path traversal vulnerability can result in a wide array of attacks against an organization, including data leakage, information disclosure, and remote code execution. If for example, an attacker accesses configuration files, they can collect valuable system information and then exploit further vulnerabilities, too.
In some cases, a path traversal vulnerability could be combined with other types of cyber attack, such as local file inclusion or execution of arbitrary code into the server. This could then compromise the whole system.
Examples of Path Traversal Vulnerability Attacks
Depending on the goal of a path traversal attack, there are many examples you can use to help understand how they work. In our example above, where users are requesting to view a document, a website may allow this by using the filename as part of a URL. It could look like this:
http://website.com/view?file=document.txtHowever, without proper sanitization on this input, a threat actor may manipulate this URL to access sensitive system information, for example with:
http://website.com/view?file=../../etc/passwdThis URL now directs the server to move up two directory levels, which could grant access to system files, including potentially providing the attacker with user information.
As a separate example, imagine an application where users are able to view images which are hosted on the server, using a legitimate input string such as:
http://website.com/view?file=profile.jpgWith malicious intent, an attacker could use the following code:
http://website.com/view?file=../../config.phpThis would allow them to access the config.php file, which may include secrets, API keys, connection credentials and more — providing a foothold to leverage further access into the environment.
OWASP Path Traversal Best Practices
When discussing path traversal attacks, OWASP suggests the following for path traversal attack prevention:
- Make it a preference where it is possible to work without user input when using file system calls.
- Rely on indexes rather than actual portions of file names when templating or using language files.
- Ensure that the user cannot supply all parts of the path by surrounding it with your custom path code.
- Validate user input by only accepting known good responses, rather than sanitizing the data.
- Restrict where files can be obtained from or saved to by using code access policies and chrooted jails.
- In situations where you need to use user input for file operations, normalize the input before utilizing any in file io APIs.
Path Traversal Attack Prevention Through Secure Coding Practices
In general, there are also additional secure coding practices that developers can implement in order to achieve path traversal attack prevention.
Input validation and sanitization is one approach that can reduce risk. If organizations only allow specific permitted characters for filenames or directory paths, this means that attackers cannot enter their own custom commands. As a general rule, special characters such as . . /, %2e should be blocked or encoded so they cannot be used. Role-based access control can also help with implementing the principle of least privilege, so that critical data and files cannot be accessed by those who don’t need them.
Another best practice is to use absolute paths instead of relative paths when referencing files. Absolute paths mean that files will be accessed from a secure directory which has been chosen ahead of time and validated. As OWASP recommends, you can also try to avoid using user input in file operations at all. One idea is to use mapping to map the file to an internal ID or handle rather than allowing a user to input file=document.pdf for example.
In some cases, your programming language of choice may provide functions that help to mitigate path traversal vulnerabilities. Examples include PHP, where the function realpath() resolves the full absolute path, Java where java.nio.file.Path.normalize() can be used, or Path.GetFullPath() in .NET.
Your Path Traversal Cheat Sheet: How to Leverage Checkmarx One for Holistic Application Security
As part of Checkmarx One, Static Application Security Testing (SAST) can be used to detect path traversal vulnerabilities at the earliest stages of the Software Development Lifecycle (SDLC).
By analyzing source code and binaries without executing the code, developers can detect these kinds of vulnerabilities early and remediate them before they add risk. SAST is able to automatically detect input validation issues, or unsanitized user inputs which if unchecked, can then be passed to file path operations. Your development team can use SAST to validate user input against a whitelist of permitted paths, ensure proper use of platform-specific APIs, and detect dangerous functions or behaviors which may lead to path traversal attacks.
Unlike open-source SAST tools, at Checkmarx, our SAST is integrated directly into the IDE, and functions alongside the developer tools that are part of developers’ everyday workflow. This not only encourages developer adoption, but also empowers developers to implement security scanning and fixes as part of their usual processes, making security part of their responsibility. Software development teams are able to identify and address vulnerabilities that could lead to path traversal long before the code reaches production, securing applications at the earliest stages, before they add risk or require costly rework to fix.
Interested in implementing holistic application security that gives developers the tools to remediate vulnerabilities as they work? Schedule a demo of Checkmarx One.