Web Vulnerabilities – File Inclusion

Views: 31

Path Traversal

Also known as Directory traversal, a web security vulnerability allows an attacker to read operating system resources, such as local files on the server running an application. The attacker exploits this vulnerability by manipulating and abusing the web application’s URL to locate and access files or directories stored outside the application’s root directory.

Path traversal vulnerabilities occur when the user’s input is passed to a function such as file_get_contents in PHP.

Local File Inclusion (LFI)

The most common place we usually find LFI within is templating engines. In order to have most of the web application looking the same when navigating between pages, a templating engine displays a page that shows the common static parts, such as the header, navigation bar, and footer, and then dynamically loads other content that changes between pages. Otherwise, every page on the server would need to be modified when changes are made to any of the static parts. This is why we often see a parameter like /index.php?page=about, where index.php sets static content (e.g. header/footer), and then only pulls the dynamic content specified in the parameter, which in this case may be read from a file called about.php. As we have control over the about portion of the request, it may be possible to have the web application grab other files and display them on the page.

File Inclusion vulnerabilities can occur in many of the most popular web servers and development frameworks, like PHP, NodeJS, Java, .Net, and many others.

With PHP, using functions such as include, require, include_once, and require_once often contribute to vulnerable web applications. 

In PHP, we may use the include() function to load a local or a remote file as we load a page. If the path passed to the include() is taken from a user-controlled parameter, like a GET parameter, and the code does not explicitly filter and sanitize the user input, then the code becomes vulnerable to File Inclusion. Let’s example the following code from a website which offers it’s pages in two different languages, English and Dutch.

<?PHP 
	include($_GET["lang"]);
?>

The lang parameter is directly passed to the include() function. The PHP code above uses a GET request via the URL parameter language to include the file of the page. The call to load the chosen language can be done by sending the following HTTP requests: http://webapp.nlabs/index.php?lang=EN.php (to load the page in English) or http://webapp.nlabs/index.php?lang=NL.php (to load the page in Dutch), where NL.php and EN.php files exist in the same directory. If there is no proper input validation, this gives as an opportunity to access and display any readable file (such as /etc/passwd) on the server, by sending the following request: http://webapp.nlabs/index.php?lang=/etc/passwd.

This attack is possible because there isn’t a directory specified in the include function and no input validation.

Let’s consider another example where the developer decided to specify the directory inside the function.

<?PHP 
	include("languages/". $_GET['lang']); 
?>

In the above code, the developer decided to use the include function to call PHP pages in the languages directory only via lang parameters.

If there is no proper input validation, then the attacker can still manipulate the URL by replacing the lang parameter with other sensitive files such as /etc/password.

Here the target URL looks like,

http://webapp.nlabs/index.php?lang=../../../../etc/passwd

The following table shows which functions may execute files and which only read file content:

Source

Error messages disclose significant information.