0

I'm testing a Java application that tries to prevent ZipSlip by simply checking whether the filename contains ".." or "./"

Since it's not a web application, I guess encoding is not an option. So, how can ZipSlip still happen in this case?

1 Answer 1

0

Preventing upward path traversal (by preventing the unpacking of files with a .. element in their path) is a common and sufficient way to mitigate ZipSlip-type vulnerabilities. It obviously does need to be done on the version of the file name that the application will pass to the file system (or, if the application canonicalizes the path before passing it to the OS, on the version of the path that is combined with the target directory to produce the canonical path). Thus if there's any decoding going on that needs to happen before the check, but in most cases that doesn't apply; the file path is stored inside the zip archive, not passed directly through HTTP or whatever.

Note that this approach can cause false positives. For example, a file called "what... is that.txt" will alarm a naive check for ".." but doesn't contain it as a directory element and thus wouldn't cause upward path traversal. Similarly, a path "foo/bar/../baz.jpg" is just a safe (but sketchy) equivalent to "foo/baz.jpg" and won't cause problems (unless you're trying to prevent any subdirectories at all, which should be done by checking for the directory separator instead). On the other hand, maybe you don't care about the site not tolerating weird-but-technically-safe file paths.

Checking for ./ doesn't make a lot of sense (though checking for ../ does, as that is much more likely to be an upward path traversal). ./ is simply the file system path equivalent of a no-op; it is a directory element that refers to the current directory, rather than the parent directory or any other.

2
  • I was hoping to find something like null byte injection that could bypass this check. I think that just using file.contains("..") instead of checking the actual final path seems pretty ugly
    – Lucius
    Oct 21 at 14:26
  • Java doesn't care about null bytes in strings, and AFAIK there's no way to encode file names within Zip such that you could fool such a check (though I'd love to hear of one!). Checking for both ../ and ..\ (ignore the space, SE markdown for comments broke; the first is standard but lots of zip files use the second) rather than just .. would get fewer false positives. Actually cracking the path and checking each element individually for being .. would be better still. However, any of these will work, in the sense of blocking the attack.
    – CBHacking
    Oct 21 at 23:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .