What is LFI (Local File Inclusion) Vulnerability ?

Local File Inclusion is an attack technique in which attackers trick a web application into executing or exposing files on a web server, and we can definitely say that its existence can be very dangerous for a website.

As you can see in the title, LFI stands for Local File Inclusion. An LFI vulnerability in a web application can trick the application into downloading arbitrary files from a restricted server. LFI can lead to the disclosure of critical information or even remote code execution. The LFI problem occurs when the application uses the path as input to retrieve files from the system. If the application does not properly sanitize the user input and blindly trusts it, an attacker can use this misconfiguration and It can affect the confidentiality of the company, which can be enough to say that this problem can be created by a programmer who is not aware of LFI.

This vulnerability is caused by a flaw in the code, and as I said, we can consider it a programming bug. Suppose there is a web application that allows you to share files over the Internet. Therefore, the main flow of the application will be like this: you upload the file first, then the website saves the file you uploaded in some folders, for example, the uploads folder on the server, now another person comes with the registration. It downloads the file and this happens exactly where the programmer makes a mistake and the vulnerability occurs.

Lets say the file is stored on a path root/vulnerablewebsite/all_files/file_sharing/upload.. Lets now see an example vulnerabe php code for downloading the files from server.

<?php
//get file name from user
$file = $_GET['file'];
//Reteieve file
include(",/uploads/$file");
?>

As you can see above, this code does not filter user input in any way, and this is a big mistake. An attacker can use this small, now-large item to return to other folders using the website input name parameter, and can rename the file as vulnerable.com/download?filename=../../.. Send /../../../etc. /passwd.

The server executes this code and returns to the root folder such as upload folder>>file sharing>>all_files>>vulnerable website>>root and retrieves the contents of the passwd file in the root folder. Here ../ will take a step back. In this way, an attacker can have unauthorized access to the system or other sensitive files of the server, if the website owner has no knowledge of this issue and is breaking eggs behind the website (it was for fun). These files can contain application code, cookies, access tokens, user information, passwords, etc., which are extremely critical to the owner. Therefore, it questions the confidentiality of the company and practically leaves nothing for it.

Stripping traversal delimiters(../): A website may use a filter that strips ../ It can be bypassed by using delimiters two times like ….//….//. Let’s see an example for the same:

If we provide input: [vulnerable. com/downloads?name=../../etc/passwd]

If it strips../ we will be left with just vulnerable. com/download?name=etc/passwd

This will not provide us with the desired output. However, if we use ….//….//….//….//etc/passwd It will strip ../ and we will still be left with ../.. /../../etc/passwd

2. Blocking relative path: A website may block relative path by blocking traversal sequence but may allow absolute path. So, we can just enter /etc/passwd and can retrieve the file.

3. Blocking traversal delimiters(../): A webapp may have a firewall placed in server with rule that checks the user input before forwarding it, if it finds the input contains traversal sequence it drops the request. This filter can be bypassed by using different encodings (like URL encoding).

Example encoded request would be like

vulnerable. com/dowload?name=..%2f..%2f..%2f..%2fetc%2fpasswdvulnerable. com/download?name=%2e%2e%2f%2e%2e%2fetc%2fpasswd

4. Validating on file extension: Lets say we have a webapp that shows images and the url is filename=image1.png if we try to just write /etc/passwd we would be blocked. This filter can be easily bypassed by using NULL character. when server executes the input it will stop at NULL character because it represents end-of-line and we will be left with just LFI payload.

vulnerable. com/images?name=../../../etc/passwd%00.png »

This will be executed as

vulnerable. com/images?name=../../../etc/passwd

LFI can be encoded and tested by double coding or using other methods, thereby bypassing the filters. We may also have to go back several steps because we don’t know exactly where the files are located on the server and obviously we have to do trial and error. We can also use payload lists to quickly check for this vulnerability.

We can put this type of attack in the category of dynamic attacks because its nature gives us this, so we can’t use direct methods to test or attack through this vulnerability, so developers use filters or mechanisms. They use various methods to block and stop attacks, and in the same way, a competent attacker must use various methods to bypass and deceive these types of web programs for arbitrary loading.