An attacker can use Local File Inclusion (LFI) to trick the web application into exposing or running files on the web server. An LFI attack may lead to information disclosure, remote code execution, or even Cross-site Scripting (XSS). Typically, LFI occurs when an application uses the path to a file as input. If the application treats this input as trusted, a local file may be used in the include statement.

Local File Inclusion is very similar to Remote File Inclusion (RFI). However, an attacker using LFI may only include local files (not remote files like in the case of RFI).

The following is an example of PHP code that is vulnerable to LFI.

/**
* Get the filename from a GET input
* Example - http://example.com/?file=filename.php
*/
$file = $_GET['file'];

/**
* Unsafely include the file
* Example - filename.php
*/
include('directory/' . $file);

In the above example, an attacker could make the following request. It tricks the application into executing a PHP script such as a web shell that the attacker managed to upload to the web server.

http://example.com/?file=../../uploads/evil.php

In this example, the file uploaded by the attacker will be included and executed by the user that runs the web application. That would allow an attacker to run any server-side malicious code that they want.

This is a worst-case scenario. An attacker does not always have the ability to upload a malicious file to the application. Even if they did, there is no guarantee that the application will save the file on the same server where the LFI vulnerability exists. Even then, the attacker would still need to know the disk path to the uploaded file.

Directory Traversal

Even without the ability to upload and execute code, a Local File Inclusion vulnerability can be dangerous. An attacker can still perform a Directory Traversal / Path Traversal attack using an LFI vulnerability as follows.

http://example.com/?file=../../../../etc/passwd

In the above example, an attacker can get the contents of the /etc/passwd file that contains a list of users on the server. Similarly, an attacker may leverage the Directory Traversal vulnerability to access log files (for example, Apache access.log or error.log), source code, and other sensitive information. This information may then be used to advance an attack.

Finding and Preventing Local File Inclusion (LFI) Vulnerabilities

Fortunately, it’s easy to test if your website or web application is vulnerable to LFI and other vulnerabilities by running an automated web scan using the Acunetix vulnerability scanner, which includes a specialized LFI scanner module. Request a demo and find out more about running LFI scans against your website or web application.

Frequently asked questions

LFI is a web vulnerability caused by mistakes made by a programmer of a website or web application. If an LFI vulnerability exists in a website or web application, an attacker can include malicious files that are later run by this website or web application.

Also read about a related vulnerability – remote file inclusion (RFI).

Luckily, LFI is not a very common vulnerability. According to the latest Acunetix Web Application Vulnerability Report, it is present on average in 1% of web applications.

Learn more about the current state of web security.

LFI can be dangerous, especially if combined with other vulnerabilities – for example, if the attacker is able to upload malicious files to the server. Even if the attacker cannot upload files, they can use the LFI vulnerability together with a directory traversal vulnerability to access sensitive information.

Read more about directory traversal vulnerabilities.

The most efficient way to detect LFI is by using an automated vulnerability scanner. You can of course detect such vulnerabilities through manual penetration testing but it takes a lot more time and resources.

Learn about the relationship between vulnerability scanning and penetration testing.

To avoid LFI and many other vulnerabilities, never trust user input. If you need to include local files in your website or web application code, use a whitelist of allowed file names and locations. Make sure that none of these files can be replaced by the attacker using file upload functions.

Read more about general secure programming habits.

SHARE THIS POST
THE AUTHOR
Ian Muscat

Ian Muscat used to be a technical resource and speaker for Acunetix. More recently, his work centers around cloud security and phishing simulation.