Path Traversal

Usually I skip straight to the solutions, but I think it is interesting to study some of the attempts we’ve seen in the past that try (and fail) to prevent path traversal.

Doing a search and removal for ../ in the given path.

• The idea behind this technique is that if you prevent a user from using ../ in the path, they’ll never be able to traverse out of the /var/www directory and into more private directories. However, this can easily be bypassed with URL encoding. The URL encoding for ../ is %2E%2E%2F, so the following would break through this defense.
• Doing a check to make sure the path ends in .html or some other known extension. This is also easy to bypass. If you stick a null byte right before also inserting the expected extension, the suffix check will succeed, but the file system will use the specified path only up to the null byte and stop reading there. Since an attacker can’t stick a regular null byte into a URL, they again rely on URL encoding to help them.

That said, there are a lot of right ways to mitigate and help prevent path traversal. Any of these solutions work in isolation, but I recommend doing as many of these as you can.

• To prevent path traversal in your web server, update your web server and operating system to the latest versions available. This vulnerability has been known for a while, and it is likely your web server’s latest version is not vulnerable. You don’t want to be stuck running an old, vulnerable web server, because then none of the below solutions will help you.
• When making calls to the filesystem, you should not rely on user input for any part of the path.
• If you must somehow open paths depending on user input, you should have the user input be an index into one of a list of known, safe files. For example, ‘1’ could map to table.html, and ‘2’ could map to chair.html.
• Run your web server from a separate disk from your system disk (the disk that holds critical operating system files), and, if possible, don’t store any sensitive files in the web server disk.
• Use filesystem permissions judiciously. Use a non-superuser to run the web server whose permissions only allow them to read only the files it needs to run. It should not be able to write to any files, since all user data should be stored in a separate database.
• If you really, really need to allow users to specify a path, relative or otherwise, then normalize the path (this is how Java does it, and it works pretty well) and check that its prefix matches the directory they should be allowed to access.

If you have an existing web application, and you want to know if you’re vulnerable to path traversal, checking is easy, but extremely tedious. For each parameter, URL, or cookie, you could insert a relative paths to files known to exist on your web server’s machine, such as ../../../../../../etc/passwd on Unix-like machines. You’d also have to see if you’re vulnerable to tricks such as ../ removal (by using %2E%2E%2F) and file extension checking (by sticking a null byte, %00, before the inserting the valid extension).

As you can imagine, this can get tedious and impractical, so I recommend using an automated web security scanner. Synopsys Web Scanner and Synopsys API Scanner are designed specifically to handle vulnerability tests like this, and it will crawl your entire site looking for path traversal vulnerabilities, among many others.