AppSec Blog

Top 25 Series - Rank 13 - PHP File Inclusion

Last year, when we got going with our web honeypot, we quickly found that file PHP file inclusion vulnerabilities are by far the #1 exploit the honeypot was exposed to [1]. In part, this may have been due to us heavily emulating PHP applications. But many of the exploits didn't match any of the installed applications and obviously got sent blindly. In another blog post, I recently summarized some of the attacks from our weblogs, and again untargeted, "dumb" remote file inclusion came out ahead. The Top 25 list assigned CWE #98 the rank of 13 [2].

What is PHP file inclusion about? This is a flaw exploiting the unintended use of a particular dangerous PHP feature. A full fatured programing language, like PHP, typically provides a feature to include additional files. This feature is frequently used to include libraries, headers or other pieces of code common to multiple pages. PHP adds a little twist to this: The file does not have to be local. If a URL is provided, like, the file is included from this bad URL. Vulnerable sample code would look like:


Code like this may be seen in an application that allows the inclusion of different configuration or header files, depending on the context in which the application is use. Obviously, if this data is not validated, a remote URL may be specified and code located at the remote URL will be executed.

Simple remote file execution like this is pretty easily avoided by turning of the "allow_url_fopen" and "allow_url_include" feature. But carefull: Depending on your version of PHP, the "ftp://" url may still work, and other special prefixes like "php:" will not be affected.

Even if remote inclusion is prevented by the server configuration, there is still a change that local inclusion will happen. For example, the malicious user could specify a configuration file to be included.

Which brings us back to our main defense: Input validation. Include files have to be carefully validated. Best: During the application design ensure that simple file names are used that are easy to validate. Maybe only a list of specific file names is allowed, or file names have to be alphanumeric.

Specifying the extension is of little use. For example, if the include statement reads:


A value ending in %00 will cause the extension to be discarded. url.php?file=/etc/password%00 may still work in this case.



Posted March 11, 2010 at 6:11 PM | Permalink | Reply


A couple good ways to mitigate this type of issue:
Block any directory traversal (best method):
$file = basename($_GET[''blah']);
Allow subdirectory only traversal, but block parent directory access (alternative, less secure):
$file = preg_replace(''/\\.+/','.',$_GET[''blah']);
You can then do something like: include($path_to_root_dir . $file) and block any nasty directory traversal issues yet allow subdirs. Just make sure to specifiy the path, or you can still get root level access.
Also, don't forget to validate that the file actually exists and is not a directory, or you might find yourself listing out directory entries on *nix.

Posted June 30, 2010 at 5:15 PM | Permalink | Reply

php institute in orissa

Really nice post, keep it up.

Post a Comment


* Indicates a required field.