Testing for Directory Traversal

Revision as of 08:00, 6 November 2006 by Ikkisoft (Talk | contribs)

Jump to: navigation, search

OWASP Testing Guide v2 Table of Contents

Brief Summary

Nowadays, many web applications use and manage files. Using input validation methods not well designed, an aggressor could exploit the system in order to read/write files that are not intended to be accessible; in particular situations it could be possible to execute arbitrary code or system commands.

Description of the Issue








Black Box testing and example

(a) Input Vectors Enumeration
As others unvalidated input vulnerabilities, in which an aggressor exploit the insufficient validation/sanitization process, also for the directory traversal flaw is necessary to consider each parameter whose value is provided by the users: form parameters (GET/POST), values inside cookies, values stored into databases from previous client-server interactions, others HTTP header parameters.

Examples of checks to be performed at this stage include:

  • Do you notice some parameters which you could recognize as file related into HTTP requests?
  • Strange file extension?
  • Curious variable name?
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed

(b) Exploit Techniques

As next step, during the assessment, we need to analyze the different attack techniques used by an aggressor in order to evaluate the input validation functions present into the web application.

Using the previous examples:


To exploit this flaw, an aggressor needs some knowledge on where to blindly find any default files and directories on the system: guessing and trying again until the attack works is usually an easy way to perform a directory climbing.


For the cookies example, we have:


It's also possible to include files (scripts too!) located on external website. Let's see:




The component called "main.cgi" is located into the same directory of the normal HTML static files used by the application. Sometimes, when the attackers are not so lucky, they need to use special chars (like the "." dot, "%00" null, ...) in order to bypass file extension controls and/or stop the script execution.

It's also very important to notice that when developers implement an input validation function sometimes they don't consider every possible chars encoding. During a Black Box Test is useful to try to inject every kind of chars encoding and also every kind of path definition.

Each operating system use different chars as path separator:

Unix-like os:

"/" root directory
"/" directory separator

Windows os:

"<drive letter>:\" root directory 
"\" but also "/" directory separator


Classic Mac os:

"<drive letter>:" root directory
":" directory separator

We should take in account the following chars encoding:

  • URL encoding e double URL encoding
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.
..%c0%af represents ../
..%c1%9c represents ..\

Gray Box testing and example


ASP: include file, include virtual, ...


For PHP, we can use:


During a Gray Box Testing is usually possible to discover vulnerabilities that are impossible (or very difficult!) to find performing a Black Box assessment.

Some web applications generate dynamic pages using values and parameters stored into a database; if an attacker could insert crafted directory traversal strings when the application saves the data, probably it will occurs a sort of "indirect" directory traversal attack. This kind of security problems is difficult to find because the parameters inside the inclusion functions seem internal and "safe" but otherwise they are not.

Additionally, reviewing the source code, it is possible to analyze the functions that are supposed to handle invalid input: some developers try to massage invalid input to make it valid, avoiding warnings and errors. This functions are usually prone to security flaws.

Considering a web application with these instructions:

filename = Request.QueryString(“file”); 

An aggressor could exploit the flaw, as in following example:

file= ..\..\boot.ini 


  • Security Risks of Unicode


  • phpBB Attachment Mod Directory Traversal HTTP POST Injection



  • Web Proxy (Burp Suite[5], Paros[6], WebScarab[7], Suru Web Proxy[8])
  • Enconding/Decoding tools
  • String searcher (grep[9], your favorite text editor)

OWASP Testing Guide v2
