Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm writing a simple HTTP server in Lua and while I can easily find resources on how to secure against Unix directory traversal, I already found some caveats in the Windows version. While I'm already looking for C:\ at the beginning (C being "any letter" here), ../ and /.. (with backslash as the directory delimiter as well) and \\ at the beginning. The code will be passed to ANSI C fopen(), compiled under Microsoft Visual C++ v10 (no idea what's the system call this call compiles to). Are there any other traps I should look out for in this case?

I'm only interested in solutions involving the modification of my code, most preferably by checking the filename against patterns.

share|improve this question
I really hope this is just a project for the sake of learning. – Terry Chia Sep 12 '13 at 13:27
It is. Here's the code: – d33tah Sep 12 '13 at 13:27
Ah, you mean the HTTP server I wrote? More of a demo, with a big warning "don't use it on production". Yet I'd rather make it secure. Its main use scenario is simple file (or directory) sharing over a trusted network. – d33tah Sep 12 '13 at 13:28

Paths in Windows are relatively complex. In particular, Microsoft has a habit of inventing new features, so even if your HTTP server is really protected against path traversal today, it may become vulnerable under next version of Windows, possibly even a small update.

Right now, your are using "blacklist-thinking": you are trying to enumerate all the "bad" constructions, and specifically detect them. Blacklists are known to be fragile because it is very hard to be exhaustive, and then to remain exhaustive. You should use whitelist-thinking, i.e. define a syntax for allowed paths and exclude everything else.

For instance, define that an allowed path consists in a sequence of components separated by slash characters ("/", not "\"), with the following rules:

  • A component contains only letters, digits, dashes ("-"), underscores ("_") or dots (".").
  • A dot may not appear as first or last character in a component.
  • There shall not be any two consecutive dots in a component.
  • A component contains at least one character, and at most 64 characters (arbitrary limit).
  • No two consecutive slashes may appear in a path.
  • A path does not begin with a slash.
  • A path is not empty.
  • The total length of a path shall not exceed 250 characters.

All these rules are easy to enforce programmatically. And they guarantee a "clean local path" that you can send to fopen(). Note that most Windows functions are perfectly happy with the "/" as separator, but you may still want to replace all slashes by backslashes (after checking all the rules above, of course).

share|improve this answer
Is 'component' just the word you are using for a directory? Because it is valid (but perhaps misguided) for a filename to be test......txt, for example, which would violate the two-dot rule. – Gray Sep 12 '13 at 13:56
Yes, I am using "component" as meaning "directory or file". The point is that, for a HTTP server, I don't actually need to support every possible path name; I just have to support paths which "make sense". I can declare that test......txt will not be allowed, even if the underlying Windows would have accepted it. (Similarly, IIS, the HTTP server from Microsoft, will reject file names which contain a "+", even though Windows itself has no problem whatsoever with such names -- and rejecting names with a "+" is very rarely an issue.) – Tom Leek Sep 12 '13 at 14:02
Thank you for the clarification. I can see your point now. – Gray Sep 12 '13 at 16:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.