What is a local file inclusion vulnerability?

File inclusions are part of every advanced server-side scripting language on the web. They are needed to keep web application code tidy and maintainable. They also allow web applications to read files from the file system, provide download functionality, parse configuration files, and do other similar tasks. However, if not implemented properly, attackers can exploit file inclusion capabilities to craft a local file inclusion (LFI) attack that may lead to information disclosure, cross-site scripting (XSS), and remote code execution (RCE).

How do local file inclusions work?

Usually, the path of the file that you want to open is sent to a function that can then return the content of the file as a string, print it on the current web page, or include it into the document and parse it as application code in the relevant language.

Typical uses and dangers of local file inclusion

Scenario 1: Including files to be parsed by the interpreter

To keep website code readable and modular, you will usually split it into multiple files and directories, ideally separated into logical pieces. To tell the interpreter where those files are, you have to specify the correct file path and pass it to a function. This function will open the file and include it inside the document. This way, the parser sees it as valid code and interprets it accordingly.

For example, you might create several different modules for one page and then include using the GET parameter with the filename of the respective function:

https://example.com/?module=contact.php

How this can lead to a local file inclusion vulnerability

If the developer fails to implement sufficient filtering, an attacker might be able to exploit a local file inclusion vulnerability by replacing contact.php with the path of a sensitive file, such as the passwd file that contains passwords on a Unix system. This will let the attacker see its content:

https://example.com/?module=/etc/passwd

In a similar scenario, a malicious hacker could exploit the LFI vulnerability by injecting code from somewhere else on the web server and tricking the parser into interpreting it as instructions. A good way to do that is to upload an image file that actually contains malicious code, such as:

https://example.com/?module=uploads/avatar102.gif

Directory traversal

Through the exploitation of a local file inclusion vulnerability, an attacker can also perform a directory traversal (path traversal) attack. For example, the attacker can exploit the above mentioned issue to access other files on the web server, such as the web server log files (e.g. error.log and access.log) or other files that may contain sensitive metadata about the web application and web server.

Scenario 2: Including files that are printed to a page

Sometimes you need the output of a file to be shared across multiple web pages, for example a header. file This comes in handy especially if you want the changes of such file to be reflected on all the pages where it is included. Such a file could be plain HTML and does not have to be interpreted by any parser on the server side, though it can also be used to show other data, such as simple text files.

For example, say you have a collection of .txt files with help texts and want to make them available through a web application. These files are reachable through a link such as:

https://example.com/?helpfile=login.txt

In this scenario, the content of the text file will be printed directly to the page without using a database to store the information.

How this can lead to a local file inclusion vulnerability

If no proper filtering is implemented, an attacker could change the link to something like https://example.com/?helpfile=../secret/.htpasswd to retrieve the password hashes of a .htpasswd file, which typically contains the credentials of all users that have access to restricted areas of the webserver.

The attacker might also be able to access and read the content of other hidden configuration files containing passwords and other sensitive information.

Scenario 3: Including files that are served as downloads

Some files are automatically opened by web browsers when accessed, such as PDF files. If you want to serve files as downloads instead of showing them in the browser window, you have to add an additional header instructing the browser to do so. If you include the header Content-Disposition: attachment; filename=file.pdf in the request, the browser will download the files instead of opening them.

For example, you might have your company brochures in PDF format and visitors to your website will use this link to download them:

https://example.com/?download=brochure1.pdf

How this can lead to a local file inclusion vulnerability

If there is no sanitization of the request, an attacker could request the download of files that make up the web application itself, allowing them to read the source code and possible find other web application vulnerabilities or read sensitive file contents. Combining this with directory traversal, the attacker might be able to use the same function to read the source code of the file connection.php:

https://example.com/?download=../include/connection.php

If the attacker finds the database user, host, and password values, they can connect to the database remotely using the stolen credentials. At this stage, the malicious hacker can execute database commands and compromise the web server (if the database user has file write privileges).

The dangers of local file inclusion attacks

As shown above, the impacts of exploiting a local file inclusion vulnerability vary from information disclosure to complete compromise of the system. Even in cases where the included code is not executed, it can still give an attacker enough valuable information to mount a successful attack. While older methods of exploiting the first scenario by including the access.log file won’t work anymore on most modern systems, there are other methods that can still lead to a complete system compromise through evaluated script code.

Preventing local file inclusion vulnerabilities in your web applications

The exploitation of a local file vulnerability on a web application can have a highly negative impact. In fact, the LFI vulnerability was listed in the OWASP top 10 list of most critical web application vulnerabilities. It is crucial to follow these secure coding practices to minimize the risk of LFI attacks and develop more secure web applications.

How to safely allow users to read or download files

• Save the file paths in a database and assign an ID to each of them. That way, users can only see the ID and are not able to view or change the path.
• Use a whitelist of files and ignore every other filename and path.
• Instead of including files on the web server, store their content in databases where possible.
• Instruct the server to automatically send download headers and not execute files in a specific directory such as /download/. That way, you can point the user directly to the file on the server without having to write additional code for the download. An example link could look like https://example.com/downloads/brochure2.pdf

What you should NOT do to avoid LFI vulnerabilities

• Do not blacklist filenames. Attackers have a huge variety of filenames to include for information disclosure or code execution and maintaining a blacklist to cover everything is practically impossible. It also is not enough to block files commonly used for testing against LFI, like /etc/passwd or /etc/hosts.
• Do not use user input as a source for file inclusions.
• Do not remove or blacklist character sequences. There are known bypasses for such filtering.
• Do not encode file paths with base64, bin2hex, or similar functions, as this can be reversed relatively easily by an attacker.

Vulnerability classification and severity table