Category:Path Traversal Attack - Revision history

KirstenS: /* Examples */

2008-08-05T12:10:48Z

‎Examples

Jeff Williams at 02:39, 19 August 2006

2006-08-19T02:39:04Z

Cturra: Initial content

2006-08-18T22:50:48Z

Initial content

Weilin Zhong at 17:48, 5 July 2006

2006-07-05T17:48:33Z

New page

This category of attacks exploit various [[:Category:Path Vulnerability|Path Vulnerabilities]] to access files that are not intended to be accessed.

[[Category:Attack]]

{{Template:Stub}}

@@ Line 9: / Line 9: @@
 We can observe from the above that bar.cgi takes a parameter to navigate through the application; in this case, the store location is mystore.html. We can use this knowledge to attempt the retrieval of bar.cgi's source code by submitting: http://foo.com/bar.cgi?store=bar.cgi
-This can be taken a step further. By combining the two methods above one may be able to retrieve server resident content using the application as a means of accessing it. Keep in mind, the web server daemon (process) runs as a user on the machine and as such the application has read access to certain areas. Using the foobar store example URL above, let look at how we can grab a file from another location of the server: http://foo.com/bar.cgi?store=../../secretfile.txt
+This can be taken a step further. By combining the two methods above one may be able to retrieve server resident content using the application as a means of accessing it. Keep in mind, the web server daemon (process) runs as a user on the machine and as such the application has read access to certain areas. Using the foobar store example URL above, let's look at how we can grab a file from another location of the server: http://foo.com/bar.cgi?store=../../secretfile.txt
 ==Categories==
 [[Category:Attack]]

@@ Line 1: / Line 1: @@
 ==Description==
-A Path Transversal attack is the technique in which one forces access to directories, files and or commands that can cause some adverse effect on the web server. This can be accomplished by attacking either the server or application level.
+This category of attacks exploit various [[:Category:Path Vulnerability|path vulnerabilities]] to access files or directories that are not intended to be accessed. This attack works on applications that take user input and use it in a "path" that is used to access a filesystem. If the attacker includes special characters that modify the meaning of the path, the application will misbehave and may allow the attacker to access unauthorized resources. This type of attack has been successful on web servers, application servers, and custom code.
 ==Examples==
-The most basic Path Transversal attack uses the '../' special character sequence to alter the location of the request. In an Operating System, this special character combination notes to move down one directory. An example of such an attack could look like the following: http://foo.com/../../barfile
+The most basic Path Traversal attack uses the '../' special character sequence to alter the location of the request. In an Operating System, this special character combination notes to move down one directory. An example of such an attack could look like the following: http://foo.com/../../barfile
 While the web server may stand up well to such an attack, another approach is to target the application itself. Most commonly the use of parameters being passed by the application can be exploited. Such data can come from user input or application data being passed between pages. Let's take for the following example into account: http://foo.com/bar.cgi?store=mystore.html
@@ Line 9: / Line 9: @@
 We can observe from the above that bar.cgi takes a parameter to navigate through the application; in this case, the store location is mystore.html. We can use this knowledge to attempt the retrieval of bar.cgi's source code by submitting: http://foo.com/bar.cgi?store=bar.cgi
-This can be taken a step further. By combining the two methods above one may be able to retrieve server resident content using the application as a means of accessing it. Keep in mind, the web server daemon (process) runs as a user on the machine and as such the application has read access to certain areas. Using the foobar store example URL above, let look at how we can grab a file from another location of the server: http://foo.com/bar.cgi?../../secretfile.txt
+This can be taken a step further. By combining the two methods above one may be able to retrieve server resident content using the application as a means of accessing it. Keep in mind, the web server daemon (process) runs as a user on the machine and as such the application has read access to certain areas. Using the foobar store example URL above, let look at how we can grab a file from another location of the server: http://foo.com/bar.cgi?store=../../secretfile.txt
 ==Categories==
 [[Category:Attack]]

← Older revision		Revision as of 22:50, 18 August 2006
Line 1:		Line 1:
−	~~This category of attacks exploit various [[:Category:~~Path ~~Vulnerability\|Path Vulnerabilities]]~~ to ~~access~~ files that ~~are not intended to~~ be ~~accessed~~.	+	==Description==
		+	A Path Transversal attack is the technique in which one forces access to directories, files and or commands that can cause some adverse effect on the web server. This can be accomplished by attacking either the server or application level.

		+	==Examples==
		+	The most basic Path Transversal attack uses the '../' special character sequence to alter the location of the request. In an Operating System, this special character combination notes to move down one directory. An example of such an attack could look like the following: http://foo.com/../../barfile
		+
		+	While the web server may stand up well to such an attack, another approach is to target the application itself. Most commonly the use of parameters being passed by the application can be exploited. Such data can come from user input or application data being passed between pages. Let's take for the following example into account: http://foo.com/bar.cgi?store=mystore.html
		+
		+	We can observe from the above that bar.cgi takes a parameter to navigate through the application; in this case, the store location is mystore.html. We can use this knowledge to attempt the retrieval of bar.cgi's source code by submitting: http://foo.com/bar.cgi?store=bar.cgi
		+
		+	This can be taken a step further. By combining the two methods above one may be able to retrieve server resident content using the application as a means of accessing it. Keep in mind, the web server daemon (process) runs as a user on the machine and as such the application has read access to certain areas. Using the foobar store example URL above, let look at how we can grab a file from another location of the server: http://foo.com/bar.cgi?../../secretfile.txt
		+
		+	==Categories==
	[[Category:Attack]]		[[Category:Attack]]
−
−	~~{{Template:Stub}}~~