As demonstrated in this blog post, though, if any of us intend to roll our own we really need to pay attention to things like this!

This is one of the reasons I advocate using frameworks or CMSes for websites. Let an existing product do the heavy lifting so that you can concentrate on writing your business logic. There are literally dozens of free CMS packages out there, and no reason not to start using one right away. (my personal favorite is Drupal, YMMV)

I used to work in web hosting and it breaks my heart to see exploited code like this everywhere.

It got to the point that our sysadmins modified the servers to include the url of the script that sent any mail message, making it easier to find and disable. Any mail sent from php included a header similar to:
X-scripted-mail: web42.example.com/~nesman/htdocs/includes/forms.php

I’ve seen so much of this that it makes me a very careful coder but I always worry that my best efforts won’t be enough. After all, the people that get exploited thought they had done enough as well.

Reading this blog post has drawn my attention to one old site that “validates” using:
if(file_exists(‘./include/’ . $_GET[‘page’] . ‘.php’))
Now it turns out that this is vulnerable as far as traversing to the parent directory and try to execute index.php. But since this is harmless, unless there’s a counterexample that allows remote inclusion even if the include path starts with ‘./’ then there’s not much incentive for me to fix it.

Again, the purpose of our example is to be a good example of good security to people who may not have seen one before. If you look at it with the attitude of “security — why bother?” you probably won’t get much out of it. It only takes a couple of extra lines written one time to get it right.

As far as incentive, you are absolutely right. The people who make this mistake aren’t the ones that suffer for it; we are. If “it’s the responsible thing to do” isn’t a good enough reason, I expect we will have to find a way to start charging for the hours we spend each week cleaning up the resulting messes. -jdw

I always validate user input to include() [although I don’t have anything hosted on NFSN that needs that right now], but typically my validation consists of looking for slashes rather than your more proactive solution; since you can’t do malicious URL fetches without slashes, what benefit is there to getting rid of anything with any characters you might not want at the risk of characters (underscores, dashes, Unicode) that you might need later?

Also, if you’re just using a PHP script to put headers and footers onto otherwise static HTML, it might be more worthwhile to do the HTML generation statically, with (say) a Python-script that takes in a folder of flat files and spits out static HTML files. (This is what I do.) Not only does it entirely remove the risk of making a code goof and ending up with an exploitable site, but it also saves a few cents by allowing you to deploy your site as static.

The include($_GET[“…”]) approach is based on mapping a portion of a URI to a portion of a filename, so you want to make sure you limit yourself to a subset of characters that work well in both places. Sure, if you want to allow other characters, go ahead. Underscore and dash probably won’t cause havoc. Unicode certainly might.

Static generation is always a great approach, but the include($_GET[“…”]) approach only has any appeal at all because it’s so easy. Static generation tends not to be, hence doesn’t appeal to the same crowd. -jdw

<?php
## PUT YOUR SITE HEADER HERE

	$pages = array(
		'home' => 'home.php',
		'about' => 'about.php',
		'events' => array(
			'announcements.php',
			'calendar.php'
		),
		'removeCookies' => 'functionA'
	);

if(empty($_GET['page']))
	$_GET['page'] = 'home';

if(isset($pages[$_GET['page']])) {
	$actions = $pages[$_GET['page']];
	if(!is_array($actions))
		$actions = array($actions);

	foreach($actions as $action) {
		if(is_callable($action))
			call_user_func($action);
		else
			@include("{$_SERVER['NFSN_SITE_ROOT']}/protected/pages/{$action}.php");
	}
}else{
	echo 'The command you requested is not allowed.';
}

## PUT YOUR SITE FOOTER HERE
?>

I’m a big fan of the whitelist approach, and we almost mentioned it, but it does take extra effort on an ongoing basis since you have to touch that file every time you add a page. NearlyFreeSpeech uses a similar approach internally, and it’s well worth it, but the extra work still makes it a “no sale” for a lot of people. -jdw

First, to the extent your approach is “straightforward,” that’s because you omitted any form of error detection, validity checking, or problem reporting. All you’ve done is changed a call to preg_match() to basename() and deleted basically everything else. Properly implemented, your example would be exactly the same size and complexity as ours. Conversely, the example code can be equivalently oversimplified:

$template = isset($_GET["page"]) ? preg_replace("/[^A-Za-z0-9_]/", "", $_GET["page"]) : "default";
include "../protected/templates/$template.php"; // You should run file_exists() on this path, and 404 out if it returns false

However, my position is that your example cannot be properly implemented because it discards vital information.

-jdw

The two issues (securing include() and properly locating secondary files) aren’t directly related, but we wanted to provide a “good role model” example of the right way to do it, and part of the right way to do it is to keep the secondary files out of the web-accessible tree. That’s just good site design and good security. -jdw

Handily, PHP includes the basename() and pathinfo() functions that all but eliminate this issue – not only for remote file inclusion attacks as demonstrated above, but also directory traversal attacks (i.e., vulnerable.php?page=../protected/hiddenFile.txt) and other similar exploits.

You can then do something very simple like the following:

<?php $template = isset($_GET['page']) ? basename($_GET['page']) : 'default';
include "../protected/templates/$template.php"; // You should run file_exists() on this path, and 404 out if it returns false
?>