Testing for Directory Traversal - Revision history

Christina Schelin: Redirected page to Testing Directory traversal/file include (OTG-AUTHZ-001)

2015-04-14T15:44:26Z

Redirected page to Testing Directory traversal/file include (OTG-AUTHZ-001)

Mmeucci: Replacing page with 'This article is moved here: http://www.owasp.org/index.php/Testing_for_Path_Traversal'

2008-08-14T08:30:01Z

Replacing page with 'This article is moved here: http://www.owasp.org/index.php/Testing_for_Path_Traversal'

Show changes

KirstenS: /* Description of Path Traversal Vulnerabilities */

2008-08-11T21:56:19Z

‎Description of Path Traversal Vulnerabilities

KirstenS: /* Description of NAME Vulnerabilities */

2008-08-11T21:55:28Z

‎Description of NAME Vulnerabilities

KirstenS: /* Description of NAME Vulnerabilities */

2008-08-11T21:55:01Z

‎Description of NAME Vulnerabilities

KirstenS at 21:54, 11 August 2008

2008-08-11T21:54:49Z

Rick.mitchell: /* Gray Box testing and example */ - Reviewed

2008-07-16T16:06:07Z

‎Gray Box testing and example: - Reviewed

Rick.mitchell: /* Black Box testing and example */ - Reviewed

2008-07-16T14:58:01Z

‎Black Box testing and example: - Reviewed

Rick.mitchell: /* Description of the Issue */ - Reviewed

2008-07-16T14:52:16Z

‎Description of the Issue: - Reviewed

Vishalg2000: /* Description of the Issue */

2007-03-28T13:55:59Z

‎Description of the Issue

← Older revision		Revision as of 15:44, 14 April 2015
Line 1:		Line 1:
−	~~This article is moved here:~~	+	#REDIRECT [[Testing Directory traversal/file include (OTG-AUTHZ-001)]]
−	~~http:~~/~~/www.owasp.org/index.php/Testing_for_Path_Traversal~~

← Older revision		Revision as of 21:56, 11 August 2008
Line 12:		Line 12:

	See the OWASP article on [[Relative Path Traversal]] Vulnerabilities.		See the OWASP article on [[Relative Path Traversal]] Vulnerabilities.
		+	[[Category:FIXME\|These both go here? Or should relative path traversal go in the related links section?]]

	===How to Avoid Path Traversal Vulnerabilities===		===How to Avoid Path Traversal Vulnerabilities===

@@ Line 7: / Line 7: @@
 ==Related Security Activities==
-===Description of NAME Vulnerabilities===
+===Description of Path Traversal Vulnerabilities===
 See the OWASP article on [[Path Traversal]] Vulnerabilities.

← Older revision		Revision as of 21:55, 11 August 2008
Line 10:		Line 10:

	See the OWASP article on [[Path Traversal]] Vulnerabilities.		See the OWASP article on [[Path Traversal]] Vulnerabilities.
		+
	See the OWASP article on [[Relative Path Traversal]] Vulnerabilities.		See the OWASP article on [[Relative Path Traversal]] Vulnerabilities.

@@ Line 4: / Line 4: @@
 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>
 == Description of the Issue ==

@@ Line 126: / Line 126: @@
 == Gray Box testing and example ==
-When the analysis is performed with a Gray Box approach, we have to follow the same methodology as in the Black Box Testing. However, since we can review the source code, it is possible to search the input vectors (''stage ('''a''') of the testing'') more easily and accurately.
+When the analysis is performed with a Gray Box approach, we have to follow the same methodology as in Black Box Testing. However, since we can review the source code, it 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.
+During a source code review we can use simple tools (such as the ''grep'' command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.
 <pre>
@@ Line 135: / Line 135: @@
 </pre>
-Using online code search engines (Google CodeSearch[http://www.google.com/codesearch], Koders[http://www.koders.com/]) is also possible to find directory traversal flaws into OpenSource software published on Internet.
+Using online code search engines (Google CodeSearch[http://www.google.com/codesearch], Koders[http://www.koders.com/]) it may also be possible to find directory traversal flaws in OpenSource software published on the Internet.
 For PHP, we can use:
@@ Line 142: / Line 142: @@
 </pre>
 <br>
-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.
+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.
+Some web applications generate dynamic pages using values and parameters stored in a database. It may be possible to insert specially crafted directory traversal strings when the application adds data to the database. This kind of security problem 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.
@@ Line 155: / Line 155: @@
 </pre>
-Testing for the flaw is acheived by:
+Testing for the flaw is achieved by:
 <pre>
 file=....//....//boot.ini

@@ Line 26: / Line 26: @@
 == Black Box testing and example ==
 ('''a''') '''Input Vectors Enumeration'''<br>
-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.
+In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts 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?
+* Parameters which you could recognize as file related HTTP requests?
 * Strange file extensions?
-* Interesting variable name?
+* Interesting variable names?
 <pre>
 http://example.com/getUserProfile.jsp?item=ikki.html
@@ Line 49: / Line 49: @@
 ('''b''') '''Testing Techniques'''
-The next stage of testing is analysing the input validation functions present into the web application.
+The next stage of testing is analyzing 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 information 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
+To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.
 <pre>
@@ Line 70: / Line 70: @@
 </pre>
-The following example will demonstrate how is it possible to show the source code of a CGI component, without using any path traversal chars.
+The following example will demonstrate how it is possible to show the source code of a CGI component, without using any path traversal chars.
 <pre>
 http://example.com/main.cgi?home=main.cgi
@@ Line 76: / Line 76: @@
 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.
+In some cases the tester needs to encode the requests using special characters (like the "'''.'''" dot, "'''%00'''" null, ...) in order to bypass file extension controls or to prevent script execution.
 <b>Tip</b>
-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.
+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 successful, try another encoding scheme.
-Each operating system use different chars as path separator:
+Each operating system uses different chars as path separator:
 ''Unix-like OS'':
@@ Line 94: / Line 94: @@
 directory separator: "\" but also "/"
 </pre>
-(Usually on Win, the directory traversal attack is limited to a single partition)
+(Usually on Windows, the directory traversal attack is limited to a single partition.)
 ''Classic Mac OS'':

@@ Line 6: / Line 6: @@
 == Description of the Issue ==
-Traditionally 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 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 represent a physical directory on the file system; users have 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 or 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 access to sensitive files from malicious users (example: the common ''/etc/passwd'' on a Unix-like platform) or to avoid the execution of system commands.
 Many web applications use server-side scripts to include different kinds of files: it is quite common to use this method to manage graphics, templates, load static texts, and so on. Unfortunately, these applications expose security vulnerabilities if input parameters (i.e. 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, this kind of problem arises in directory traversal/file include attacks; exploiting this kind of vulnerability an attacker is able read directories or files which he/she normally couldn't read, access data outside the web document root, or 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.
+For the purpose of the OWASP Testing Guide, we will just consider the security threats related to web applications and not to web servers (i.e. the infamous "%5c escape code" into Microsoft IIS web server). We will provide further reading suggestions in the references section, for interested readers.
-This kind of attack is also known as the '''dot-dot-slash''' attack (../), '''path traversal''', '''directory climbing''', '''backtracking'''.
+This kind of attack is also known as the '''dot-dot-slash''' attack (../), '''path traversal''', '''directory climbing''', or '''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)
+* ('''a''') '''Input Vectors Enumeration''' (a systematic evaluation of each input vector)
 * ('''b''') '''Testing Techniques''' (a methodical evaluation of each attack technique used by an aggressor to exploit the vulnerability)
 <br>