A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with a “dot-dot-slash (../)” sequence and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on the file system including application source code or configuration and critical system files. It should be noted that access to files is limited by the system’s operational access control, such as in the case of locked or in-use files on the Microsoft Windows operating system.
This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.
An attacker may be able to read or write unauthorized files on the file system by exploiting this vulnerability. The result could be disclosure of sensitive information, credentials, or source code. An attacker could also use this as one step in an attack to write executable code to the server, which would enable a complete host takeover if executed.
How to solve it
Ideally, the application would not use user input when accessing the file system. Explore the possibility of using a token or other index to reference files rather than passing around file paths or names. The token can be a key in a Map that lists allowed files. If the map has no corresponding value for the key given, then report an error.
Alternatively, validate the user input very carefully before using it to access the file system. Here is an example of a typical path traversal vulnerability:
An attacker can abuse this functionality to view the /etc/passwd file on a UNIX system by passing the following value for the "statement" parameter:
The NULL byte (%00) is just another char to Java, so the malicious value passes the "endsWith()" check. However, when the value is passed to the operating system's native API, the NULL byte will represent an end-of-string character, and open the attacker's intended file. Note that Null byte injection in Java was fixed in Java 7 Update 40. So, make sure you are using at least this version of Java, in addition to validating the user's input to this File accessor code.
How to protect yourself
- Try to work without user input when using file system calls
- Use indexes rather than actual portions of file names when templating or using language files (ie value 5 from the user submission = Czechoslovakian, rather than expecting the user to return "Czechoslovakian")
- Ensure the user cannot supply all parts of the path - surround it with your path code
- Validate the user's input by only accepting known good data - do not sanitize the data
- Use chrooted jails and code access policies to restrict where the files can be obtained or saved to
- If forced to use user input for file operations, normalize the input before using in file I/O API's, such as http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#normalize().