We know that there are many ways in which hackers attack our assets. They can vary from internal or external threats; security breaches or to our servers. One of the most common attacks that companies usually receive and is almost unknown are inclusion attacks. There are different types: Remote File Inclusions (RFI), Local File Inclusions (LFI) and Cross-site scripting. Although the names are similar, in practice they are very different.
They attack different points of our defense for different reasons. Today we will know what they are, what their differences are and how to combat them.
Remote File Inclusion Attacks
When using remote file inclusion, an attacker includes a remote file in a web application. This type of attack is possible for web applications that include dynamic files. Inclusion attacks of this type generally occur when an application receives a file. If this route is not “disinfected”, the possibility of intrusion opens up. This gives the attacker access to provide an external URL to the inclusion function.
The consequences of a successful RFI attack vary with each case. These range from the disclosure of confidential information and the theft of cross-site scripting; to remote code execution that can completely alter the functionality of our applications. An attacker could, for example, use an embedded PHP script. Through this script, you could make HTTP requests to fool the affected applications. This way, you can get apps to execute malicious code on the server-side without knowing that it is malware.
The danger of such files can even reach the theft of privileges. Including a malicious file can run with the privileges of the user of the web app. That allows an attacker to execute any code he wants; either on the webserver or within the application. They can even maintain their presence on the web server without detecting.
How to detect and prevent Remote File Inclusion?
Knowing this, it’ll be easy to test if your website or web app is vulnerable to inclusion attacks. Within the most effective ways for this detection, we have the execution of an automated web scan. Acunetix vulnerability scanner is an example, one of the most important in the market. Once detected, the best way to end these inclusions is to avoid including files based on user input. If this is not possible, you can make a “white list” of files included in the application.
However, entry validation will be less effective this way; because attackers can avoid it in some way or another. In the case of PHP, most of the installations start with allow_url_include disabled. This makes it impossible for malicious users to include remote files. Yet, the inclusion of local files (LFI) is still possible in this case, so we will talk about it now.
Local File Inclusion Attacks
Local file inclusion is very like remote file inclusion. Yet, such an attacker can only include local files (not remote files as in the case of RFI). A hacker can use this type of inclusion attacks to deceive the web application. In this way, I was able to expose or execute files on the server. You can also get the disclosure of confidential information; remote code execution or even cross-site scripting (XSS).
Typically, this kind of attack occurs when an application uses the path to a file as input. If the application adopts this entry as reliable, a local file can be used in its declaration of inclusion. This way, it tricks the application into running a PHP script, such as a web shell. But it would be one embedded by the attacker, which would then upload to the web server.
Let’s say the file uploaded by the inclusion attacks gets included and executed by the user running the web application. This would allow an attacker to execute any malicious code on the server-side he wants. But this is the worst case, an extreme situation. An attacker does not always have the ability to load a malicious file into the application.
Even if it did, there is no guarantee that it will work. You could find the file or the app could save the file to another server with no LFI vulnerability. Even then, the attacker would still need to know the path of the disk to the loaded file to execute it.
How to detect and prevent Local File Inclusion?
It is easy to check if your website or web application is vulnerable to LFI. By executing an automated web scan using a scanner, you will get the right answer. Acunetix scanner, for instance, includes a specialized module for LFI that ensures success in detection. Cross-site scripting attacks.
Cross-site Scripting
Cross-site Scripting (XSS) is a code injection attack, like LFI or RFI. Yet, XSS occurs on the client-side. The purpose of these attacks is to execute malicious scripts in the victim’s web browser. This is achieved by including malicious code on a web page. But, the actual attack occurs when the victim visits the web page or app that executes the malicious code.
This kind of inclusion attack turns the page or app into a vehicle to deliver the malicious script. And this inclusion occurs in the browser of those who access these services. The most common vehicles for XSS are forums, message boards, and comment websites.
To stay safe from XSS, you must disinfect your inbound services. Achieving this prevents the code in your app from generating data received as input to the browser without checking for malicious code.
If you want to receive more information about this tool, do not hesitate to contact us. At GB Advisors we offer the best in the market; and we offer you a team of professionals willing to advise you and go with you on your way to a more efficient IT environment.
