Local File Inclusion (LFI)

Description

Local File Inclusion (LFI) is a type of security vulnerability that occurs when a web application includes files on the server without properly validating user input. In most cases, the application receives a file path from a client-side parameter (for example, ?page= in a URL) and dynamically uses this path to include content in the response. If the application does not adequately sanitize or validate that path, attackers can manipulate it to access sensitive files on the host system.

The core issue arises from user input being passed into file handling functions (e.g., include, require in PHP, file reads in other languages) that treat that input as a trusted file path. By leveraging path traversal sequences such as ../, an attacker might be able to read arbitrary files on the server (like system logs, configuration files containing credentials, or even application source code).

LFI can escalate into more severe attacks if attackers manage to include and parse files that contain malicious code or user-submitted content. In some scenarios, LFI can lead to Remote Code Execution (RCE), but even when limited to file reads, it can expose critical information, facilitate further attacks, and compromise privacy.

Examples

Simple Path Traversal

// Vulnerable code snippet
<?php
    $page = $_GET['page'];  // For example, ?page=index
    include($page);         // No input validation
?>

An attacker could exploit this by passing:

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

attempting to read the server's /etc/passwd file (if permissions allow).

Log File Inclusion Leading to Code Execution

Some applications write user input to server logs. If an attacker can write PHP code into a log (for instance, by manipulating the User-Agent header) and then include that log file via the vulnerable parameter, the PHP code can be executed.

Example request:

GET /vulnerable.php?page=../../../var/log/apache/access.log

where the log file might contain malicious code that the server interprets.

Commonly Targeted Files:

  • /etc/passwd or /etc/shadow on UNIX systems.
  • config.php or wp-config.php in web application directories (leaking database credentials).
  • Error logs or access logs that may contain other exploitable information or even injected malicious code.

These examples highlight how an attacker can leverage unvalidated file inclusion to read system files or escalate the impact through file injection.

Remediation

  1. Input Validation and Whitelisting

    • Never trust user-supplied paths.
    • Maintain an explicit whitelist of allowable file names or paths if dynamic includes are necessary. For example, map user-friendly input values (?page=help) to internal, verified file names (/path/to/help.php).

  2. Parameterized Routing / Avoid Direct include

    • Rather than accepting file paths directly, use a controlled routing mechanism. For example, store all legitimate include files in a single directory and use a lookup table.
    • If a legitimate file must be included, ensure its path is strictly verified (e.g., using realpath checks or directory checks).

  3. Least Privileges and Hardened Server Configuration

    • Limit file system permissions so that the web application user has only the minimum necessary access. This reduces the impact if a vulnerability is exploited.
    • Disable risky functions (like allow_url_include or even allow_include in some configurations) in the PHP settings when not needed.
    • Consider using open_basedir restrictions in PHP to confine file operations to specific, safe directories.

  4. Filtering and Encoding

    • Remove or encode special characters from user input (e.g., ../) that enable path traversal.
    • In some cases, implementing stringent filtering can reduce exposure to LFI attacks, though whitelisting is typically more secure than blacklisting.