Local File Inclusions (LFI), explained

When building a web application, developers must focus on both user functionality and user security. A single security issue can have a dramatic impact on the credibility of your organization and the security of your users.

Server-side scripting languages, like PHP and JavaScript, use inclusions to open files. An “inclusion” refers to dynamically loading a file that your application needs. However, when not properly implemented and validated, file inclusions can be exploited by unscrupulous actors to open up other local files on your server.

This article discusses the ins and outs of local file inclusions: how they work, what the impacts of local file inclusion vulnerabilities may be, and how to prevent them.

Let’s get started!

What is a local file inclusion?

A local file inclusion happens with certain programming languages when a server dynamically loads a file into the application.

A malicious person can abuse a local file inclusion to open files you don’t want them to open. This exploit happens when user input is not sanitized, which means user-entered information that might be unsafe is left exposed. For example, it’s unsafe to allow user input to directly construct a file path because this opens up an opportunity to add a malicious input path.

Let’s take a look at local file inclusion attacks for both PHP and JavaScript.

Use case: PHP local file inclusion

A very simple example of a local file inclusion attack using PHP can be seen below. Here, we request user input to determine which file to open through the file parameter. Next, we directly use the $file variable in the include statement.

As you can see, when you pass blog.php as input, you get the following path: directory/blog.php. However, when we pass ../../../etc/passwd, we get a malicious path that opens up the possibility for the user to access a sensitive system file: directory/../../../etc/passwd. The passwd file contains sensitive system data, namely, passwords.

Tip: Check out the PHP security checklist by Sqreen.

Use case: JavaScript local file inclusion

Local file inclusion attacks are also possible with JavaScript. For example, your application may read data from a file. The I/O function expects a file path from which to read data.

To construct this path, we use a function that joins a base path with a path input by the user. Again, if you don’t validate the user input, a malicious path can be constructed. Here’s an example of such an attack with JavaScript.

As you can see, if you do not validate the inputPath parameter, a user can directly add malicious input to the path.join function for JavaScript. For example, as seen above, a path such as ../.env, tries to access the environments file for your application that contains lots of secrets.

Tip: Download the Node.js Security handbook to improve the security of your Node.js apps.

What’s the impact of a local file inclusion vulnerability?

Local file inclusion vulnerabilities can impact your web application in various ways. For example, here are three possible abusive outcomes of local file inclusions:

  • Information disclosure
  • Directory traversal
  • Remote code execution

Let’s take a closer look at each of these outcomes.

1. Information disclosure

First of all, a local file inclusion vulnerability can lead to information disclosure. For example, you might expose a certain text file that contains information about the application. An attacker could gain access to a README file that describes important configurations of your web application.

Often, information disclosure isn’t the worst outcome. However, when attackers gain important information about your application and its configuration, it helps them find other vulnerabilities and they gain a deeper understanding of your web application.

2. Directory traversal

Second, a local file inclusion vulnerability opens up the possibility of a directory traversal attack. Here, attackers try to access files on the server, other than the files of the web application, that provide them with important information.

For example, accessing a log file can furnish attackers with valuable information about problems the web server experiences: think of error log files that often expose paths to sensitive files or reveal an application’s structure.

Another example is that an incorrectly configured server might give attackers access to user config files, such as /.bash_profile, which contains user configurations and exposes shell variables. Once they have this, attackers can access any other system file on your server. Furthermore, the attackers can gain administrator access to your server!

3. Remote code execution

Lastly, a local file inclusion vulnerability combined with a file upload vulnerability can even lead to a remote code execution attack. If attackers manage to upload an unwanted file to your server, they can abuse the local file inclusion vulnerability to execute that file.

Worst case scenario, the local file inclusion vulnerability lets the attacker upload a file to the server that gives them the ability to execute arbitrary commands remotely. This gives the attacker the opportunity to control the server remotely.

How to prevent local file inclusion?

Next, we describe different strategies to prevent local file inclusion attacks. The first and foremost lines of defense are sanitizing and validating user input. Never use unvalidated input for a dynamic file inclusion function.

Here are a couple of strategies to prevent local file inclusion attacks.

1. Whitelist accessible pages

The simplest method to avoid a local file inclusion attack is to whitelist the pages users can visit. In other words, you define an array that holds all accessible pages. Whenever a user requests a page that’s not whitelisted, you display an error message.

A shortcoming of this method is that it is not a scalable approach. Every time you want to add a new page, you’ll have to update the array. Besides that, when you have multiple dynamic inclusion functions in your web application, you’ll have to maintain a whitelisted pages array for each inclusion function.

In other words, the whitelisting approach is prone to human error.

2. Limit directory access

PHP offers an open_basedir function that allows you to limit the files that PHP can access in your filesystem. For example, you want to prevent users from accessing files outside of the root folder of your web server, such as the system passwords file /etc/passwd.

The open_basedir function is an easy way to tell PHP which files it can access and which files it can’t. However, attackers can still open files within the boundaries you’ve set and gain a deeper understanding of your web app. For example, you can’t block access to an upload folder because your application requires access to upload files.

3. Assign IDs to file paths

Assign a random ID to every file path that users will have access to. Next, store both the random ID and associated file path in your database so you can easily retrieve them. The first benefit here is that attackers would need to gain access to your database to understand the connection between IDs and file paths.

The second benefit is that whenever users visit a certain page, they get to see only the ID for that file path and not to the file path itself. This way, malicious users can’t gain any information about the file structure of your application because an ID can refer to any file path in the same folder or in any underlying folder.

Wrapping up and learning more

I hope you learned a bit about local file inclusion attacks and how you can prevent them. We hope that having a better understanding of how such attacks can happen will help you prevent them.

The best defense is to avoid loading files dynamically. If you face a situation where you do have to load files dynamically, make sure to implement the right security measures, like limiting directory access, whitelisting pages, and using random IDs to represent file paths.

In short, develop a web application with security in mind. Take a look at the OWASP top 10 security vulnerabilities to learn about other types of web application attacks.

If you want to learn more about preventing local file inclusion attacks in your application, sign up for a free trial of Sqreen. Tools like Sqreen can monitor and protect your web apps in production so you can get alerted or block attacks like local file inclusion attacks in real time. 

—-

This post was written by Michiel Mulders. Michiel is a passionate blockchain developer who loves writing technical content. Besides that, he loves learning about marketing, UX psychology, and entrepreneurship. When he’s not writing, he’s probably enjoying a Belgian beer!

Subscribe
Notify of
guest
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments