File Inclusion and Path Traversal

Overview

File inclusion and path traversal vulnerabilities appear when an application uses attacker-controlled input to build filesystem paths or include files without strong validation. The impact ranges from reading sensitive files to full remote code execution through wrappers, session files, or log poisoning. These notes cover the traversal model, LFI vs RFI, common bypasses, PHP wrapper abuse, and escalation paths.

Why This Happens

Server-side code often reads configuration files, templates, uploaded files, or other local resources. If a parameter controls the path and the application trusts that input too much, the attacker may move outside the intended directory or include unintended content.

Typical vulnerable patterns include dynamic include(), file readers, download endpoints, template loaders, and image or document handlers.

Traversal Basics

The classic traversal sequence is ../, which moves up one directory level.

• Relative path: based on the current working directory, such as ./folder/file.php.
• Absolute path: full filesystem path, such as /var/www/html/folder/file.php.

If a file parameter is weakly validated, a payload like the following may expose system files:

include.php?page=../../../../etc/passwd

LFI vs RFI

Local File Inclusion

LFI happens when the application includes a file from the local filesystem based on user input. The initial impact is usually file read or local code execution if the included file contains executable content.

Remote File Inclusion

RFI happens when the application includes a remote resource supplied by the attacker. In old or misconfigured PHP environments, this can become immediate code execution if remote URLs are accepted by include-like functions.

Basic Testing

• Find parameters named page, file, template, view, path, or similar.
• Try harmless local targets first, then known-sensitive files like /etc/passwd where appropriate.
• Watch for path disclosure, inclusion errors, or reflected file content.
• Determine whether the target is reading files as text or executing PHP as code.

Path Filter Bypasses

Naive defenses often block exact strings like ../.. or strip ../ once. Those filters are usually weak.

Base Directory Breakout

/var/www/html/..//..//..//etc/passwd

The double slashes still resolve correctly on the filesystem, but they may bypass crude substring checks.

URL Encoding

%2e%2e%2f

Double Encoding

%252e%252e%252f

Obfuscation

....//config.php

If the application strips only the obvious ../ pattern, payloads like this may collapse back into traversal after sanitization or decoding.

PHP Wrappers for File Read

PHP wrappers are a major part of LFI exploitation. The most common read-oriented wrapper is php://filter.

Example payload:

php://filter/convert.base64-encode/resource=/etc/passwd

If the application includes or reads that path, it may return a base64-encoded version of the target file. That is useful when direct binary or PHP content would otherwise break rendering.

Other useful filters include:

• string.rot13
• string.toupper
• string.tolower
• string.strip_tags

data:// Wrapper

The data:// wrapper allows inline data embedding. If the application includes it as PHP-executable content, it can become a direct code-execution primitive.

data:text/plain,<?php phpinfo(); ?>

That payload only matters if the application actually evaluates the included content as PHP. If it only reads and reflects the file, the impact is different.

Wrappers for Code Execution

Wrapper chaining can sometimes turn LFI into code execution. A common pattern is using php://filter with data:// and a base64-decoded payload.

php://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSEnOyA/Pg==

If the backend includes and executes that resource, the injected PHP can be reached through a parameter like ?cmd=whoami.

Session File Inclusion

PHP session files are another classic LFI-to-RCE path. If attacker-controlled data is written into the session and the session file is later included through LFI, injected PHP can execute.

Example vulnerable behavior:

if(isset($_GET['page'])){
    $_SESSION['page'] = $_GET['page'];
    include($_GET['page']);
}

An attacker injects PHP into session data, then includes a file like:

/var/lib/php/sessions/sess_[PHPSESSID]

If session storage is file-based and the path is reachable, that can become code execution.

Log Poisoning

Log poisoning is one of the most common LFI escalations. The attacker injects PHP code into a log file through a request line, user-agent, or header that the web server logs. Then they include the log file via LFI.

Typical target:

/var/log/apache2/access.log

Typical process:

• Send a request containing PHP code into a logged field.
• Confirm the payload landed in the log file.
• Trigger LFI against the log path.
• Reach the injected code through query parameters if needed.

What To Look For During Review

• Dynamic include(), require(), readfile(), or file-read helpers using user input.
• Path joins that rely only on string replacement or substring checks.
• Applications that prepend a base folder but do not canonicalize the final path.
• Writable log files, session files, or upload directories that may later be included.
• PHP wrappers allowed in include contexts.

Testing Workflow

• Confirm whether the sink is file read or code include.
• Test straightforward traversal first.
• Try encoded and obfuscated traversal payloads if filtering exists.
• Use php://filter to read files more cleanly.
• If execution is possible, evaluate session inclusion, log poisoning, upload inclusion, or wrapper chaining.
• Keep track of absolute paths revealed by errors because they often unlock the next step.

Mitigation

• Never use raw user input in filesystem paths or include functions.
• Use strict allowlists of known templates or file identifiers.
• Resolve and canonicalize paths before access, then verify they remain under the intended base directory.
• Disable unneeded PHP settings such as remote URL inclusion features.
• Keep logs, sessions, and uploads outside executable include paths where possible.
• Review error handling to avoid leaking filesystem layout.

Key Takeaways

• Path traversal is the filesystem navigation problem; LFI and RFI are the file inclusion outcomes built on top of it.
• LFI often starts as file read and escalates through wrappers, logs, sessions, or uploads.
• Naive string filters are easy to bypass with encoding and path obfuscation.
• php://filter is one of the most useful tools for controlled file disclosure.
• Strong path allowlisting and strict include design are the real defenses.