Path Traversal

high Web App Scanning Plugin ID 98100

Language:

Synopsis

Path Traversal

Description

Web applications occasionally use parameter values to store the location of a file which will later be required by the server.

An example of this is often seen in error pages, where the actual file path for the error page is stored in a parameter value -- for example `example.com/error.php?page=404.php`.

A path traversal occurs when the parameter value (ie. path to file being called by the server) can be substituted with the relative path of another resource which is located outside of the applications working directory. The server then loads the resource and includes its contents in the response to the client.

Cyber-criminals will abuse this vulnerability to view files that should otherwise not be accessible.

A very common example of this, on *nix servers, is gaining access to the `/etc/passwd` file in order to retrieve a list of server users. This attack would look like: `yoursite.com/error.php?page=../../../../etc/passwd`

As path traversal is based on the relative path, the payload must first traverse to the file system's root directory, hence the string of `../../../../`.

Scanner discovered that it was possible to substitute a parameter value with a relative path to a common operating system file and have the contents of the file included in the response.

Solution

It is recommended that untrusted data is never used to form a file location to be included.
To validate data, the application should ensure that the supplied value for a file is permitted. This can be achieved by performing whitelisting on the parameter value, by matching it against a list of permitted files. If the supplied value does not match any value in the whitelist, then the server should redirect to a standard error page.
In some scenarios, where dynamic content is being requested, it may not be possible to perform validation against a list of trusted resources, therefore the list must also become dynamic (updated as the files change), or perform filtering to remove extraneous user input (such as semicolons, periods etc.) and only permit `a-z0-9`.
It is also advised that sensitive files are not stored within the web root and that the user permissions enforced by the directory are correct.