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, attackers can exploit them and craft a LFI attack which may lead to information disclosure, cross-site-Scripting (XSS) and remote code execution (RFI) vulnerabilities.
How do Local File Inclusions Work?
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.
Typical Scenarios Where Local File Inclusions Are Used and Their Risks
Scenario 1: Including Files to be Parsed by the Language's Interpreter
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.
Usage Example
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:
https://example.com/?module=contact.phpThe Risks of Introducing a Local File Inclusion Vulnerability
If the developer fails to implement sufficient filtering an attacker could exploit the local file inclusion vulnerability by replacing contact.php with the path of a sensitive file such as the passwd file, where passwords are stored on a Unix system, allowing the attacker to see its content:
https://example.com/?module=/etc/passwd
In such a 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:
https://example.com/?module=uploads/avatar102.gifDirectory 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 meta data 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 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.
Usage Example
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.
The Risks of Introducing a Local File Inclusion Vulnerability
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.
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. 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.
Usage Example
You have the company brochures in pdf format and the web application visitors use this link to download them:
https://example.com/?download=brochure.pdfThe Risks of Introducing a Local File Inclusion (LFI) Vulnerability
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:
https://example.com/?download=../include/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.
Impacts of an Exploited Local File Inclusion Vulnerability
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.
Preventing Local File Inclusion Vulnerabilities in Your Web Applications
The exploitation of a local file vulnerability on a web application can have a high negative impact. In fact the LFI vulnerability was listed in the OWASP top 10 list of most critical web application vulnerabilities. So it is important to follow the below tips to develop more secure web applications.
Tips for Letting Users Read or Download Files Securely
- Save the file paths in a database and assign an ID to each of them. BY doing so 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
About Roshan Burnwal
0 Comments:
Post a Comment