Difference between revisions of "Absolute Path Traversal"

Jump to: navigation, search
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
#REDIRECT [[Path Traversal]]
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
Line 31: Line 30:
==Related [[Threat Agents]]==
==Related [[Threat Agents]]==
* [[:Category: Information Disclosure]]
==Related [[Attacks]]==
==Related [[Attacks]]==
Line 46: Line 44:
[[Category:Abuse of Functionality]]
[[Category:Path Traversal Attack]]
[[Category:Resource Manipulation]]

Revision as of 07:13, 12 February 2009

This page has been recommended for deletion.
You can help OWASP by improving it or discussing it on its Talk page. See FixME
Comment: Tagged via Template:Delete
#REDIRECT Path Traversal

Last revision (mm/dd/yy): 02/12/2009


If a product expects a filename as input it is possible that it can construct an absolute path such as "/rootdir/subdir," which is then processed by the operating system to access a file or resource that is outside of a restricted path that was intended by the developer.

This is similar to path traversal but uses only "/" and not ".." to gain access. More detailed information can be found on Path_Traversal

Risk Factors


How does the attack work?

The following URLs maybe are vulnerable to this attack:
A simple way to execute this attack is like this:
When the web server returns information about errors in a web application, it is much easier for the attacker to guess the correct locations (e.g. path to the file with a source code, which then may be displayed).

Related Threat Agents

Related Attacks

Related Vulnerabilities

Related Controls