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

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:\.