Remote File Inclusion

Remote File Inclusion (RFI) is a web application vulnerability that allows an attacker to force the application to include and execute arbitrary code hosted on a remote server under their control. It occurs when user-supplied input, such as a URL or parameter value, is passed to a file include mechanism without proper validation or sanitization, enabling the injection of external URLs that point to malicious files.

Almost all web application frameworks support file inclusion. File inclusion is mainly used for packaging common code into separate files that are later referenced by main application modules. When a web application references an include file, the code in this file may be executed implicitly or explicitly by calling specific procedures. If the choice of module to load is based on elements from the HTTP request, the web application might be vulnerable to RFI. An attacker can use RFI for: * Running malicious code on the server: any code in the included malicious files will be run by the server. If the file include is not executed using some wrapper, code in include files is executed in the context of the server user. This could lead to a complete system compromise. * Running malicious code on clients: the attacker’s malicious code can manipulate the content of the response sent to the client. The attacker can embed malicious code in the response that will be run by the client (for example, JavaScript to steal the client session cookies).

PHP is particularly vulnerable to RFI attacks due to the extensive use of "file includes" in PHP programming and due to default server configurations that increase susceptibility to an RFI attack.

Successful exploitation of an RFI vulnerability can have a critical impact on the affected system. An attacker who injects a remotely hosted malicious script gains arbitrary code execution on the server with the privileges of the web server process, potentially leading to full system compromise, sensitive data exfiltration, installation of backdoors, or lateral movement within the network.

Common exploitation vectors include injecting URLs pointing to attacker-controlled scripts through unvalidated query parameters, cookie values, or HTTP headers that feed into file include functions. Attackers may also leverage protocol wrappers (such as php://, data://, or expect://) to bypass basic filtering and execute payloads without hosting an external file. In multi-step attacks, RFI can serve as the initial foothold to deploy web shells, ransomware agents, or cryptocurrency miners on compromised infrastructure.

The most effective way to prevent Remote File Inclusion is to avoid passing user-supplied input to filesystem or file include APIs altogether. Many application functions that use dynamic file includes can be rewritten to deliver the same behavior in a safer way.

When dynamic inclusion cannot be avoided, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.

For PHP environments specifically, disable remote file inclusion by setting allow_url_include to 0 in your PHP configuration. Additionally, consider using Suhosin or similar hardened extensions that disable some of the more dangerous PHP features.

Apply strict input validation using an allow list of acceptable values that conform to specifications. For filenames, use stringent allow lists that limit the character set, allow only a single "." character to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to prevent CWE-36. Use an allow list of permissible file extensions to help avoid CWE-434.

Run your application in a sandboxed environment that enforces strict boundaries between the process and the operating system. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In Java, java.io.FilePermission in the SecurityManager allows you to specify restrictions on file operations. Be careful to avoid CWE-243 and other weaknesses related to jails.

Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server’s access control capabilities to prevent attackers from directly requesting them. A common practice is to define a fixed constant in each calling program and then check for its existence in the included file; if the constant is not set, the file was requested directly and can exit immediately.

Identify all potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.