Directory Traversal Attacks

Attackers use directory traversal attacks to read arbitrary files on web servers, such as SSL private keys and password files.

Some web applications open files based on HTTP parameters (user input). Consider this simple PHP application that displays a file in many languages:

<?php
$language = "main-en";
if (is_set($_GET['language']))
  $language = $_GET['language'];
include("/usr/local/webapp/static_files/" . $language . ".html");
?>

Assume that this PHP page is accessible through http://foo.com/webapp/static.php?language=main-en; an attacker can read arbitrary files from the web server by inserting some string to make the include function point to a different file. For instance, if an attacker made these GET requests,

http://foo.com/webapp/static.php?language=../../../../etc/passwd%00

the include function would open this file:

/usr/local/webapp/static_files/../../../../etc/passwd

This file is simply

/etc/passwd

Thus, the GET request would return the contents of /etc/passwd on the server. Note that the null byte (%00) ends the string, so .html would not be concatenated to the end of the filename.

This type of attack is called a directory traversal attack, and it has plagued many web servers for some time, because attackers would URL encode the ../ segments in various ways, such as these:

• %2e%2e%2f

• %2e%2e/

• ..%2f

• .%2e/

Countermeasure Directory Traversal Attacks

Today, some web application frameworks automatically protect against directory traversal attacks. For example, PHP has a setting called magic_quotes_gpc, which is on by default. This setting “magically” escapes suspicious characters in GETs, POSTs, and cookies with a backslash. Thus, the character / is escaped to \/, which stops this attack. Other web application frameworks do not have general protection mechanisms, and it is up to the developer to protect against these problems.