Are /../ and /./ the only file system symbolic links?

Question

I want to check that a file system path is valid and safe to use relative to another path. So I want to know if there are any other special characters like /../ and /./ which might cause a path to actually point somewhere else.

If that is all I have to worry about then a quick replace of those chars followed by something like this to check for any other bad filesystem chars should work right?

[^a-z0-9\.\-_]

(On windows stuff like C:\ would also have to be allowed)

The use case is that I have a folder which site administrators can create directories in and I want to FORCE them to only create directories in that folder. In other words, no being sneaky with ...path/uploads/../../../var/otherfolder/ if you know what I mean ;)

Answer 1

Which language are you using?

In PHP, for example, you can get the realpath of any string and then compare it to a base directory. If you find your base directoy is a prefix of the realpath, then you're good to go.

Although that's only for PHP, you should be able to find a similar approach in other languages.

Answer 2

The answer depends on the filesystem used. It's different on Windows, different on *nix.

For example, on Windows-based desktop platforms, invalid path characters might include quote ("), less than (<), greater than (>), pipe (|), backspace (\b), null (\0), and Unicode characters 16 through 18 and 20 through 25.

I don't know which platform/language are you using, but if you are using .NET you can get list of chars which cannot be in filename by calling Path.GetInvalidFilenameChars and list of chars which cannot be in path by calling Path.GetInvalidPathChars

Answer 3

There are several oddities on Windows/DOS. Opening any of these will both read and write to unexpected places. I havnt tried how .NET handles these, but I presume that you would get some kind of security exceptions.

CON   Console. Reads from keyboard, writes to screen.
      "COPY CON temp.txt", end input with ctrl-z.

PRN   Printer. (Defaults to LPT1?)
LPTn  Parallell ports.

AUX   "Auxiliary device." Have never seen anyone use this myself.

COMn  Serial ports.

NUL   /dev/null

Answer 4

Unix symbolic links can be tricky, and can even be created to cause pathing loops on some systems. You should lstat() the filename to get the actual inode and devno numbers to see if two pathnames are actually the same file.

Answer 5

Have you considered using something like chroot? You can create something called a "chroot jail" that will prevent people from getting outside it. This is enforced by the OS, so you don't have to write it yourself. Note that this only works on *nix, and on some variants of *nix, it does not have all the security features necessary to make it foolproof (i.e. there are known ways of escaping).

Answer 6

For resolving paths, ., and .., (and in most cases, // for Unix and \\ for Windows) are the main things you really need to worry about in terms of resolving paths. From RFC 3986, this is the algorithm for resolving relative paths in URIs. For the most part, it also applies to file system paths.

An algorithm, remove_dot_segments:

1. The input buffer is initialized with the now-appended path components and the output buffer is initialized to the empty string.
2. While the input buffer is not empty, loop as follows:
   1. If the input buffer begins with a prefix of "../" or "./", then remove that prefix from the input buffer; otherwise,
   2. If the input buffer begins with a prefix of "/./" or "/.", where "." is a complete path segment, then replace that prefix with "/" in the input buffer; otherwise,
   3. If the input buffer begins with a prefix of "/../" or "/..", where ".." is a complete path segment, then replace that prefix with "/" in the input buffer and remove the last segment and its preceding "/" (if any) from the output buffer; otherwise,
   4. If the input buffer consists only of "." or "..", then remove that from the input buffer; otherwise,
   5. Move the first path segment in the input buffer to the end of the output buffer, including the initial "/" character (if any) and any subsequent characters up to, but not including, the next "/" character or the end of the input buffer.
3. Finally, the output buffer is returned as the result of remove_dot_segments.

Example run:

STEP   OUTPUT BUFFER         INPUT BUFFER

 1 :                         /a/b/c/./../../g
 2E:   /a                    /b/c/./../../g
 2E:   /a/b                  /c/./../../g
 2E:   /a/b/c                /./../../g
 2B:   /a/b/c                /../../g
 2C:   /a/b                  /../g
 2C:   /a                    /g
 2E:   /a/g

STEP   OUTPUT BUFFER         INPUT BUFFER

 1 :                         mid/content=5/../6
 2E:   mid                   /content=5/../6
 2E:   mid/content=5         /../6
 2C:   mid                   /6
 2E:   mid/6

Don't forget that it's possible to do things like specify more ".." segments than there are parent directories. So if you're trying to resolve a path, you could end up trying to resolve beyond /, or in the case of Windows, C:\.

Answer 7

I've already directly answered the question, but as Tom said, what you're trying to do is inherently dangerous. What you should probably do instead is create one directory at a time. Pass it through a regexp validator and don't let them use dot segments at all. Just have a text field in a form for the directory name and a "Make Directory" button. Let them traverse the directory tree to create sub-directories. This way you can be absolutely confident that the files are going where they should.

This has the advantage of working on both Windows and *nix without the need for chroot.

Addenda:

This Regexp will only match illegitimate directory names, assuming that you're accepting directories one at a time:

/^(\.\.?|.*?[^a-zA-Z0-9\. _-]+.*?|^)$/

Valid directory names:

• "This is a directory"
• ".hidden"
• "example.com"
• "10-28-2009"

Invalid directory names:

• ""
• "."
• ".."
• "../somewhere/else"
• "/etc/passwd"
• "would:be?rejected!by;OS"