tags:

views:

233

answers:

2

I have a Java server implementation (TFTP if it matters to you) and I'd like to ensure that it's not susceptible to path traversal attacks allowing access to files and locations that shouldn't be available.

My best attempt at defending so far is to reject any entries that match File.isAbsolute() and then rely on File.getCanonicalPath() to resolve any ../ and ./ components out of the path. Finally I ensure that the resulting path is still within the required root directory of my server:

public String sanitize(final File dir, final String entry) throws IOException {
    if (entry.length() == 0) {
        throw new PathTraversalException(entry);
    }

    if (new File(entry).isAbsolute()) {
        throw new PathTraversalException(entry);
    }

    final String canonicalDirPath = dir.getCanonicalPath() + File.separator;
    final String canonicalEntryPath = new File(dir, entry).getCanonicalPath();

    if (!canonicalEntryPath.startsWith(canonicalDirPath)) {
        throw new PathTraversalException(entry);
    }

    return canonicalEntryPath.substring(canonicalDirPath.length());
}

Are there security issues that this misses? Are there better / faster to achieve the same result reliably?

The code needs to work consistently across Windows and Linux.

+1  A: 

If you're running this on a unix machine (I'm not sure if windows has something similar, but it might) you'll want to look at chroot. Even if you think you hit all the ways for someone to refer up a few directories, it's nice to have the operating system there enforcing the fact.

(chroot causes '/' to refer to some other directory, so "/" might be "/home/me/project" and "/../../.." is still "/home/me/project".)

EDIT:

There's a chroot system call as well as a chroot command-line tool. I don't know if Java has a native method, but nothing would prevent you from running your server with the command-line tool. This should, of course, be in addition to doing your best to prevent other path manipulations.

Actually that's not true, a chroot can be used to put a running process onto a completely indipendant directory tree with its own /home /var /etc... Also directory traversal within a chroot can still lead to nasty attacks, even remote code execution.
Rook
Your first statement is true, though somewhat misleading. You would generate your own mirror of the root system paths in a subdirectory - everything you need to run, including Java and related libraries.The second statement is strong hyperbole, as it links chroot with the attack by implication. If you have a hole that could lead to any attack, it should be patched as a separate issue. chroot is there to minimize the impact of any potential security concern.In the end, you cannot prove any code to be secure, you can only reduce your attack surface and decrease the potential for damage.
A: 

I don't know much about Java, but you could check out the allowed characters in filenames (http://en.wikipedia.org/wiki/Filename) and filter out all non-allowed characters (white listing) and then you could be sure you've got a filename there.

Kai Sellgren