LFI Vulnerability Tester

Understanding Local File Inclusion (LFI)

Local File Inclusion is one of those vulnerabilities that sounds narrow until you see how often it turns up in real audits. At its core, an LFI attack happens when a web application lets user-supplied input decide which file gets pulled into the page, usually through PHP's include or require statements. A developer might write code that reads a page name from the query string and includes it directly, intending only to load a handful of known templates. Left unchecked, that same line becomes a doorway: an attacker can swap in a different path, walk up the directory tree with sequences like ../../, and pull configuration files, credentials, or logs the server was never meant to expose.

People often ask how LFI differs from RFI, or Remote File Inclusion, and the distinction matters for both testing and prevention. LFI stays confined to files already sitting on the local server, while RFI tricks the application into fetching and executing a file hosted somewhere the attacker controls. RFI tends to be blocked automatically once allow_url_include is disabled, which is now the default in modern PHP builds, but LFI does not disappear with a single setting. It depends entirely on how carefully the application validates the path it is handed, which is why LFI remains a fixture in cybersecurity assessments even as RFI has faded.

What makes LFI attractive to an attacker is how far it can escalate. A simple local file inclusion exploit might only disclose a configuration file, but in the right conditions the same flaw becomes a path to code execution. Log poisoning is the classic example: an attacker plants PHP code inside a request header, that string ends up written into a server log file, and then the vulnerable include statement pulls the poisoned log back in and executes it. Combined with PHP's stream wrappers, which can read, encode, or filter file contents on the fly, a seemingly minor LFI attack can unravel into full server compromise if the underlying include logic is not locked down.

Testing for LFI responsibly starts with the code, not the internet. Rather than pointing an automated tool at a production domain and firing path traversal strings at it, the more defensible approach is to read the source, or use a static scanner, and ask a direct question: does user input ever reach an include or require call, in any form, direct or indirect? That question alone catches the majority of local file inclusion bugs before they reach production, and it does not risk knocking over a service or triggering an intrusion alert on infrastructure that is not yours to test.

Prevention, thankfully, is well understood even if it is inconsistently applied. The strongest fix is to stop treating user input as a filename at all: map a small set of allowed page identifiers to their actual file paths in an array, and reject anything that is not an exact match. Where dynamic includes are unavoidable, strip path separators, reject null bytes, and canonicalize the resolved path before comparing it against an allowed base directory. Server-level settings help too. Setting open_basedir restricts PHP to a defined directory tree, disabling allow_url_include removes the remote-fetch avenue entirely, and keeping error messages generic denies an attacker the directory structure hints that make exploitation easier.

None of this requires exotic tooling. A disciplined code review, a static scanner tuned to flag dynamic includes, and a short hardening checklist covering PHP configuration will catch the overwhelming majority of local file inclusion issues in typical web applications. The goal is not to memorize every LFI attack variant that has ever been documented, but to build the habit of treating any path that touches user input as suspicious by default, and to verify — in your own codebase, on your own terms — that the habit actually held.