Testing for Local File Inclusion

Brief Summary
File Inclusion vulnerability allows an attacker to include a file, usually through a script on the web server. The vulnerability occurs due to the use of user-supplied input without proper validation. This can lead to something as minimal as outputting the contents of the file, but depending on the severity, to list a few it can lead to:


 * Code execution on the web server
 * Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
 * Denial of Service (DoS)
 * Sensitive Information Disclosure

Description of the Issue
Local File Inclusion (also known as LFI) is the process of including local files on a server through the web browser. This vulnerability occurs when a page include is not properly sanitized, and allows directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, one should keep in mind it is also common in other technologies such as JSP, ASP and others.

Black Box testing and example
Since LFI occurs when page includes are not properly sanitized, in a blackbox testing approach one should look for scripts which take filenames as parameters. Consider the following example: http://vulnerable_host/preview.php?file=example.html

This looks as a perfect place to try for LFI. If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server. Typical proof-of-concept would be to load passwd file: http://vulnerable_host/preview.php?file=../../../../etc/passwd

If the above mentioned conditions are met, an attacker would see something like the following: root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin alex:x:500:500:alex:/home/alex:/bin/bash margo:x:501:501::/home/margo:/bin/bash ...

Very often, even when such vulnerability exists, its exploitation is a bit more complex. Consider the following piece of code: 

In the case, simple substitution with arbitrary filename would not work as the postfix 'php' is appended. In order to bypass it, a technique with null-byte terminators is used. Since %00 effectively presents the end of the string, any characters after this special byte will be ignored. Thus, the following request will also return an attacker list of basic users attributes: http://vulnerable_host/preview.php?file=../../../../etc/passwd%00

To be continued.

Gray Box testing and example
Gray box

Mitigation
How to protect yourself from LFI