By Douglas Mewis

Remote File Include (RFI) is an attack technique used to exploit “dynamic file include” mechanisms in web applications. When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application might be tricked into including remote files with malicious code. Almost all web application frameworks support file inclusion to some degree. 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.


Typically, RFI attacks are performed by setting the value of a request parameter to a URL that refers to a malicious file. Consider the following PHP code:

$incfile = $_REQUEST["file"];

The first line of code extracts the value of the file parameter from the HTTP request. The second line of code dynamically sets the file name to be included using the extracted value. If the web application does not properly sanitize the value of the file parameter (for example, by checking against a white list) this code can be exploited. Consider the following URL: In this case the included file name will resolve to:
The remote payload may look like this:  

echo “HACKER”;

$hack1 = @php_uname();

$hack2 = system(uptime);

$hack3 = system(id);

$hack4 = @getcwd();

$hack5 = getenv(“SERVER_SOFTWARE”);

$hack6 = phpversion();

$hack7 = $_SERVER[‘SERVER_NAME’];

$hack8 = gethostbyname($SERVER_ADDR);

$hack9 = get_current_user();

$os = @PHP_OS;

echo “operation system: $os”;

echo “uname -a: $hack1”;

echo “uptime: $hack2”;

echo “id: $hack3”;

echo “pwd: $hack4”;

echo “user: $hack9”;

echo “phpv: $hack6”;

echo “SoftWare: $hack5”;

echo “Server Name: $hack7”;

echo “Server Address: $hack8”;

echo “HACKER technical information retrieval”;


This payload when injected to application reveals technical information about the attacked application such as: IP address, server name, passwords and users names. This is often the start of an attack where a hacker probes your website to detect any vulnerabilities you may have.

Thus, the remote file will be included and any code in it will be run by the server. 

In many cases, request parameters are extracted implicitly (when the register_globals variable is set to On). In this case the following code is also vulnerable to the same attack:


Several easy methods to avoid RFI. The first is turn register_globals off. The register_global setting in earlier versions on most hosts is on, though lately most hosts set this off automatically now.  In PHP 6.0, this setting is removed completely. The second setting to turn off is allow_url_fopen.  This should be turned off, unless you can find an overwhelming business reason to use it.  Believe it or not, there are good business reasons to leave this on, but you really need to know what the hell you are doing with this setting. The main application vulnerability leading to RFI is a result of insufficient validation on user input. In order to perform proper validation of input to avoid RFI attacks, an application should check that user input doesn’t contain invalid characters or reference to an unauthorized external location.  In otherwords, include(), include_once(), require(), and require_once() should only reference explicitly named files and not use dynamic code.  If you must include an external file, then you should explicitly define the file path in your include or require statement.  Always whitelist which pages and files you allow to be referenced via URL submitted parameters.  An example of what I am getting here: Now assume the URL is

$page = $filter->clean($_GET['page']);  // filter input first

case 'Clean1':
// Code here to actually open the Clean 1 page
// Put code here to reload the home page - dont give the hacker any error message

As you can see, I have taken this a few steps further.  I first filtered the $_GET input against SQL injection and the code I actually use, also filters out unwanted javascript and HTML tags.  Once that is done, I have built a whitelist that loads only allowed pages.  The hackers attempt at loading a remote page will then fail here. Similarly, if you are including remote pages, make sure you filter and carefully check the user submitted URL parameters against malicious attacks and you know and trust the remote page you are including.  Keep in mind also, that you are vulnerable at two ends.  If the trusted site from which you are including files is successfully exploited and hijacked via C99 or RFI attacks, you are then vulnerable yourself as hackers will often use remote inclusion hosting sites as distribution points to disperse their malicious script across multiple sites.  Be careful if you include remote files and make sure the remote site uses top of the line security software and methods to detect RFI signature attacks and use good firewall software.

Incoming search terms:

  • rfi remote file inclusion
  • rfi echo
  • detecting RFI in websites
  • FILE INCLUSION techniques
  • malicioous file inclusion-RFI
  • RFI check parameter software
  • rfi include site
  • rfi vulnerable site
  • url malicious filename arguments