File inclusions are part of every advanced server side scripting language on the web. They are needed to keep web applications' 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. Though if not implemented properly, they can become an exploitable web vulnerability which malicious attackers can take advantage of.
Usually the path of the file you want to open is sent to a function which returns the content of the file as a string, or prints it on the current web page, or includes it into the document and parses it as part of the respective language.
To keep a website’s code readable and modular the code is usually split into multiple files and directories, ideally separated into logical pieces. To tell the interpreter where those files are you have to specify a 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.
You create several different modules for one page and to include them you use the GET parameter with the filename of the respective function, such as:
If the developer failes to implement sufficient filtering an attacker could exploit the local file inclusion vulnerability by replacing contact.php with the path of a sensitive file, which will be parsed and the attacker can see its content, such as:
In such scenario the malicious hacker could also inject code from somewhere else on the web server and let the parser interpret it as instructions to exploit the LFI vulnerability. A good way to do that is a picture upload functionality with an image containing malicious code in its source, such as:
Sometimes you need the output of a file to be shared across different 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 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.
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:
In this scenario the content of the text file will be printed directly to the page without using a database to store the information.
If no proper filtering is implemented, an attacker could change the link to something such as
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.
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. You can include the header Content-Disposition: attachment; filename=file.pdf in the request and the browser will download the files instead of opening them.
You have the company brochures in pdf format and the web application visitors use this link to download them:
If there is no sanitization of the request, the attacker could request the download of files that make up the web application, therefore being able to read the source code and possible find other web application vulnerabilities or read sensitive file contents. For example the attacker can use the same function to read the source code of the file connection.php:
If the attacker finds the database user, host and password he can connect to the database remotely with 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.
As shown above, the impacts of exploiting a Local File Inclusion (LFI) 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 be able to compromise the system. Even though old ways of exploiting the first scenario won’t work anymore on most modern systems, e.g. including the access.log file, there are still some methods that can still lead to a complete system compromise through evaluated script code.