[Path Traversal]
Path traversal vulnerabilities come about when user-controllable data is used by the
application to access files and directories on the application server or other back-end
file system in an unsafe way. By submitting crafted input, an attacker may be able to
cause arbitrary content to be read from, or written to, anywhere on the file system
being accessed. This often enables an attacker to read sensi-tive information from
the server, or overwrite sensitive files, leading ulti-mately to arbitrary command
execution on the server.
Check out the following example, in which our dummy web application uses a dynamic
page to return static images to the client. The name of the requested image is
specified in a query string parameter:
https://example.com/scripts/GetImage.php?file=IHTBr0cks.jpg
When the server processes this request, it performs the following steps:
1. Extracts the value of the file parameter from the query string.
2. Appends this value to the prefix /www/images/.
3. Opens the file with this name.
4. Reads the file’s contents and returns it to the client.
Do you see the issue yet? The vulnerability arises because an attacker can
simply add in path traversal sequences into the filename in order to backtrack
up from the image directory shown above and so access files from anywhere on the
server. The path traversal sequence is known as “dot-dot-slash,” and a typical
attack would look somthing along the lines of:
https://example.com/scripts/GetImage.php?file=../../etc/passwd
Now the application will read in the new value of the file parameter to the name
of the images directory, so our dumb application will see a path of:
/www/images/../../etc/passwd
Adding the traversal sequences allows us to step back up from the images direc-
tory to /etc directory, and doing so the application actually sees the path as:
/etc/passwd
Yay, Instead of an Image we get the systems password file..
Defending Against Traversal Attacks
After performing all relevant decoding and canonicalization of the user-
submitted filename, your app should check whether this contains either
of the path traversal sequences (using backward or forward slashes) or
any null bytes.
If so, the application should stop processing the request. It should not
attempt to perform any sanitization on the malicious filename. Hackers
do it with all sorts of characters, make sure to check more than just
../ & ... See Encodings below:
|
