I've got an application vulnerable to directory traversal (I know this because it's part of the wording of the question). The application has two directories, public and private, and two php files:

  • A.php?folder=[public|private] list the content of both directories.
  • B.php?folder=public&file=test.txt&action=[view|download] view or download the specified file.

I need to view a file called users.txt which is allocated in the private directory. B.phpseems to have a restriction that only allows the action on the public directory, so if I type B.php?folder=private&file=users.txt&action=view, actually it's trying to read \public\private\admin\users.txt (notice the backslash, it's a Windows system if that matters).

My next step was to jump back in the directory tree, but neither .. nor %2E%2E are allowed by the application. It returns a message saying that the dot char can't be used for the folder or the file.

There is no cookies nor POST data.

So, how could I "break the jail" of the public directory in B.php? Any ideas?

PS: spoke with my instructor and he confirms this is a tricky question.

  • Well first of all, there is some code preventing you from reading files, what does this code look like? We can't just magic away an error message.
    – rook
    Dec 8, 2014 at 15:36
  • @Rook it's a black box testing. The message it returns is just a string saying that "Error, using '..' is forbidden in folder and file name.
    – user15194
    Dec 8, 2014 at 16:01
  • Try injecting your canocolizations into both the parameters names and values
    – atdre
    Dec 8, 2014 at 17:06
  • have you tried using other URL parameters in A.php? It is supposed to just list the contents but perhaps it responds to the action and/or file parameters.
    – mcgyver5
    Dec 8, 2014 at 17:12
  • @mcgyver5 didn't think about that, but just tried and if I replace folder with anything else, there is a 302 to folder=public which is the default page.
    – user15194
    Dec 8, 2014 at 17:18

1 Answer 1


I can't tell you how to break that specific system as there is not enough information supplied, although I can provide some general things to try:

  • Try / and \ at the start of the folder name to try and reach the root directory.
  • Try %2f and %5c (percent encoded versions of the above).
  • Try using 16-bit Unicode encoding (. = %u002e, / = %u2215, \ = %u2216).
  • Try double URL encoding (. = %252e, / = %252f, \ = %255c).
  • Try overlong UTF-8 Unicode encoding (. can be %c0%2e, %e0%40%ae, %c0ae, / can be %c0%af, %e0%80%af, %c0%2f, etc, \ can be %c0%5c, %c0%80%5c).

If you suddenly get a different response then you have managed to change either the execution path or the file system path that is being accessed so you may be onto something.

You can use a tool such as Burp Suite to automate your attack and substitute different representations of path characters.

  • the application only accepts ascii and hex. It seems it doesn't properly handle 16-bit unicode, double URL encoding or UTF-8 unicode.
    – user15194
    Dec 9, 2014 at 17:55
  • @yzt: So is that beneficial to your attack or not? Dec 9, 2014 at 19:09
  • well... we can say that it is beneficial but it doesn't solve the problem. I found the answer already, it doesn't depend on encoding, but I'm accepting this as it can benefit other people with directory traversal attacks.
    – user15194
    Dec 10, 2014 at 13:15
  • @yzT: How did you break it? Dec 10, 2014 at 14:07
  • 1
    It was pretty easy... The trick was in that .. wasn't allowed, but a single dot yes, so using a dot in folder and another dot in file, I could go to the other directory.
    – user15194
    Dec 10, 2014 at 16:50

You must log in to answer this question.