File inclusion is a high-impact web vulnerability: a single mishandled page= or file= parameter can disclose server source code and, when escalated, hand an attacker remote code execution. It sits under A03:2021 - Injection in the OWASP Top 10 (CWE-98, closely related to CWE-22 path traversal).
How dynamic inclusion executes code
Many applications pick which page or module to load at run time from a request parameter. PHP is the most commonly exploited server-side language for this flaw: the web server runs .php files as programs before sending the result to the browser, unlike static HTML files which are only read and forwarded. The developer intends ?page=home to load home.php:
<?php include($_GET['page'] . '.php'); ?>PHP's include/require family does not merely read the target — it executes any code inside it in the application's context. So whoever controls the path controls which code the server runs.
The same anti-pattern exists in other stacks (a view name resolved from input, Server-Side Includes, classic ASP Server.Execute), but the canonical, most-exploited form is the PHP include sink — which is why this lesson requires an external authorised lab.
Why the impact is severe
- Read primitive. Pull arbitrary local files —
/etc/passwd, configuration files with database credentials, application source. - Code execution. Escalate a local read into Remote Code Execution (RCE) via log poisoning or executable PHP wrappers, or fetch and run a remote payload (RFI) when remote includes are enabled.
What you will do in this lesson
- Recognise how a user-controlled parameter flows into a file-include sink.
- Distinguish LFI from RFI, and inclusion from plain path traversal.
- Read a local file through the parameter, then learn three escalation techniques that turn a file-read into code execution: log poisoning (inject PHP into a server log file the application already writes, then include that log to execute it), **
php://filter(a PHP stream wrapper that reads and base64-encodes source files without executing them, useful for extracting source code), anddata://** (a wrapper that lets you supply inline PHP code as the inclusion path itself). - Learn the durable fix.
Required external lab. NovaCart has no PHP-style include sink, so use the DVWA "File Inclusion" module or the PortSwigger Web Security Academy path-traversal / file labs. If you do not already have DVWA running, follow the Docker setup steps in virtualization-lab-fundamentals — it can run in a container alongside NovaCart.
Estimated time: 10 to 15 minutes.
Scope reminder: practise these techniques only in your DVWA lab or an authorised environment such as a PortSwigger Web Security Academy lab. Reading files from a server you do not own — or escalating to code execution — constitutes unauthorised access and is illegal in most jurisdictions.
When you are ready, send the Continue signal.