File inclusion

Directory map

• Intro to file inclusions — LFI basics, templating, impact, examples (PHP, Node, Java, .NET), read vs execute
• Local file inclusion (LFI) — exploitation basics, traversal, prefixes, extensions, second-order

Summary

File inclusion flaws happen when HTTP parameters or path segments choose a file to load or render, and that choice is not safely constrained. Local File Inclusion (LFI) lets attackers read (or sometimes execute) arbitrary server files—common around templating patterns such as index.php?page=about where the page fragment maps to an include path. Impacts include source disclosure, secret leakage (keys, credentials, configs), and under some primitives remote code execution. Examples span PHP (include / require / file_get_contents and friends), Node (fs.readFile, path.join breakout, res.render with interpolated paths), Java/JSP (jsp:include, c:import), and .NET (Response.WriteFile, @Html.Partial, SSI includes). A key review axis is read-only vs execute and local vs remote URL support: execution-capable includes (e.g. PHP include, some c:import / SSI cases) widen blast radius to RCE, while read-only sinks still enable credential and logic leakage. Defensive themes are allowlisting, canonical path checks, and never wiring raw request data into filesystem or template resolution.

For exploitation mechanics, see local-file-inclusion.md: swapping parameters for system files (e.g. /etc/passwd), ../ path traversal when a directory is prepended, /-led payloads when a filename prefix is concatenated, the effect of appended extensions (and why bypasses are a separate topic), second-order LFI via stored fields (e.g. usernames used in download paths), and the lab distinction between reading PHP source vs executing it.