File inclusion vulnerability

A file inclusion vulnerability is a type of vulnerability that is most commonly found to affect web applications that rely on a scripting run time. This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. A file include vulnerability is distinct from a generic Directory Traversal Attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution. Successful exploitation of a file include vulnerability will result in remote code execution on the web server that runs the affected web application.

Remote File Inclusion (RFI) occurs when the web application downloads and executes a remote file. These remote files are usually obtained in the form of an HTTP or FTPURI as a user-supplied parameter to the web application.

Local File Inclusion (LFI) is similar to a Remote File Inclusion vulnerability except instead of including remote files, only local files i.e. files on the current server can be included for execution. This issue can still lead to remote code execution by including a file that contains attacker-controlled data such as the web server's access logs.

In PHP the main cause is due to the use of unvalidated user-input with a filesystem function that includes a file for execution. Most notable are the include and require statements. Most of the vulnerabilities can be attributed to novice programmers not being familiar with all of the capabilities of the PHP programming language. The PHP language has a directive which, if enabled, allows filesystem functions to use a URL to retrieve data from remote locations.[1] The directive is allow_url_fopen in PHP versions <= 4.3.4 and allow_url_include since PHP 5.2.0. In PHP 5.x this directive is disabled by default, in prior versions it was enabled by default.[2] To exploit the vulnerability an attacker will alter a variable that is passed to one of these functions to cause it to include malicious code from a remote resource. To mitigate this vulnerability all user input needs to be validated before being used.[3][4]

The developer intended to read in english.php or french.php, which will alter the application's behavior to display the language of the user's choice. But it is possible to inject another path using the language parameter.

/vulnerable.php?language=C:\\notes.txt%00 - example using NULLmeta character to remove the .php suffix, allowing access to files other than .php. This use of null byte injection was patched in PHP 5.3, and can no longer be used for LFI/RFI attacks.[5]

/vulnerable.php?language=../../../../../etc/passwd%00 - allows an attacker to read the contents of the passwd file on a UNIX system directory traversal.

The best solution in this case is to use a whitelist of accepted language parameters. If a strong method of input validation such as a whitelist cannot be used, then rely upon input filtering or validation of the passed-in path to make sure it does not contain unintended characters and character patterns. However, this may require anticipating all possible problematic character combinations. A safer solution is to use a predefined Switch/Case statement to determine which file to include rather than use a URL or form parameter to dynamically generate the path.

A Server-Side Include are very uncommon and are not typically enabled on a default web server. A server-side include can be used to gain remote code execution on a vulnerable web server.[6] The following code is vulnerable to a remote-file include vulnerability: