In an age when we are constantly developing innovative solutions to brace against sophisticated cyber attacks, we often underestimate the havoc that can be unleashed by the benign-looking, more elementary attack forms. They may not make big headlines as the high-profile cyber attacks, but they can be disastrous as well.

This Blog Includes show

Local File Execution (LFI) and Remote File Execution (RFI) are similar to the nefarious Cross-Site Scripting (XSS) attacks. All of them are forms of code injection attack, with the former two being less sophisticated and therefore easily preventable. Although not taken seriously by the security community, LFI and RFI attacks constitute 21 percent of all observed web application attacks.

At Astra, we have a team of security experts who helped hundreds of websites to get secure from XSS, LFI, RFI, SQL Injection and 80+other security threats. Secure your website now.

30,000 websites get hacked every single day. Are you next?

Secure your website from malware & hackers using Website Protection before it is too late.

Get started

7 Days Free Trial

Understanding LFI and RFI Attacks

Remote File Inclusion (RFI) is a method that allows an attacker to employ a script to include a remotely hosted file on the webserver. The vulnerability promoting RFI is largely found on websites running on PHP. This is because PHP supports the ability to ‘include’ or ‘require’ additional files within a script. The use of unvalidated user-supplied input within these scripts generally leads to the exploitation of this vulnerability. And with more than 70 percent web sites running on PHP, RFI should be on every security researcher’s radar, but sadly it’s not. The severity of an RFI attack can range from outputting the contents of a file to arbitrary code execution.

Anatomy of a Remote File Inclusion Attack

On the other hand, Local File Inclusion (LFI) is very much similar to RFI. The only difference being that in LFI, in order to carry out the attack instead of including remote files, the attacker has to use local files i.e files on the current server can only be used to execute a malicious script. Since this form of vulnerability can be exploited with only using a web browser, LFI can easily lead to remote code execution by including a file containing attacker-controlled data such as the web server’s access logs.

Complete Step by Step Guide to WordPress Security (Reduce the risk of getting hacked by 90%)

Some notorious cases of LFI/RFI attacks are:

LulzSec, which attacked their targets using RFI bots.
TimThumb, a WordPress add-on, whose LFI vulnerability led to a compromise of 1.2 million websites.

Since more than 90% of PHP running websites run on version 5.2 or higher, LFI is almost three times more rampantly occurring than RFI. Hackers prefer LFI in websites running PHP version 5.2 or higher due to the unique functionality of an additional control mechanism over remote file include in the form of the allow_url_include switch in version 5.2. Since the default value of the switch is OFF, applications that were previously RFI vulnerable now become LFI vulnerable.

The percentage share of LFI and RFI attacks among other web application attacks. Source: Imperva monthly trend report

Mitigating RFI and LFI attacks

Mitigation of malicious file execution attacks can be done with the following preventive measures –

1. Vulnerability scanning, which includes:

Dorking – Use of Google to search hints of potential vulnerability, identify them and remove their traces from web applications
Vulnerability scanners – Use of commercial or free tools to regularly scan applications for potential vulnerabilities.

2. Web Application firewalls: A WAF can blacklist referenced URLs to block exploits targeting zero-day vulnerability of applications. A web application firewall can:

Detect attacks using a combination of application layer knowledge and a pre-configured database of attack vector formats.
Identify access patterns of automated tools
Create and deploy a blacklist of hosts that initiated attacks to quickly identify and block attackers in the future.

3. Blacklisting: Blacklisting IPs obtained from observing previous RFI attacks could be used to block any future attacks originating from the same malicious source, thus tackling an attack before it even begins.

4. Code fixing: The application code can be written in a manner that prevents RFI attacks. Therefore, enable code reviewing via your web application firewall.

Check our blog on what hackers do with a hacked website