PHP has a mechanism for including files inside each other. The architects of PHP didn’t really think much about what they were doing with a lot of the core language features (witness the foolishness over Register Globals), and file import/include/require is a classic example.

This is one of the most fundamental features of the language, and it’s screwed up. It “seems” to work, so long as you write simplistic enough / small enough apps. The bigger your app, the more likely it is you’ll discover how poor this part of the language is.

In most languages, you have a distinction between

1. importing (IMP)
2. including (INC)
3. internally-evaluating (INT)
4. externally-evaluating (EXT)

(not all languages have all of the above – most have 2 or 3 of them)

The first one runs at the language-level, and is surrounded by all sorts of careful compiletime/runtime code to manage exactly what happens. The second one runs at the source-file-level, and simply “dumps” the contents of another file inside the main file. The last two are like the second, except that they “executes” the other file, and whatever that “execution” process outputs is what gets embedded – rather than the contents of the file. They differ from each other in that one executes using all the currently-in-scope info, the other executes without any access to currently scoped data.

PHP says “**** it, I can’t be bothered with writing code properly, I”ll just pretend all four of those are identical, and I’ll name the functions as if I meant INC, even though I don’t”.

Net result: the include/require/include_once/require_once statements in PHP don’t really work properly, because they have to do the work BOTH of importing AND of including AND of evaluating … all in one go.

(by the way … this is subtly documented in the fourth paragraph of the docs for include(), but there’s no warning in the other statement/function docs)

Here’s the “compromises” that have been made (with the use-cases in brackets):

• Files are treated as plain HTML (INC)
• …but also, simultaneously, as “executable, may contain PHP tags” (EXT)
• When a file is brought in, it is only executed when that line of code is executed (INC, INT)
• The scope of anything executed is the scope of the currently-executing function (INT)
• Any (de facto) closures (in the form of defined functions) found inside the brought-in file … are shunted into the current environment (INC, IMP)

Several of those are clearly mutually incompatible already. It’s simply not possible to put all three of those features onto a single language-statement. Unfortunately … PHP has.

That’s just irritating – it means that basic PHP apps suddenly break when you add a line of code, because e.g. you’ve been using include() to do EXT, or IMP, and that was fine … but you just added some code that expose it’s incompatible behaviour by showing off some of its INT functionality (or vice versa).

But far worse is what happens when you throw “_once()” into the mix. In practical terms, it’s actually surprisingly easy to write code that doesn’t run correctly at runtime (and this is undocumented, too). Because “_once()” is, essentially, an undefined language feature.

Don’t believe me? Go read the docs. Find for me the point where they state the definition of:

“if the code from a file has already been included”

(or … don’t bother. Take my word for it – it’s not defined).

If IMP, INC, and EVAL were *not* squashed into some ugly mess like they are in PHP, this *would not be a problem*, because people would just work on the “obvious” interpretation of “has already been included”, i.e.:

you called “include*()” or “require*()” on this filename already

you called “include*()” or “require*()” on this filename AT THIS SCOPE already

What? TWO definitions? Well, yes, dear reader, because most humans will pick the first definition. It appears correct. And for IMP and EXT – by definition – it is correct, since they ignore scope. However, sadly, INC and INT explicitly require scope to be obeyed, and they *require* the second definition to be used.

Guess which definition PHP uses? Bearing in mind that PHP *treats the include() file differently* depending upon which scope it’s imported at…

Did you guess the second option? Ha! Wrong!

And so, in PHP, it’s easy to write something like this:

file 1:
if( !isset( $A) )
   $A = "not blank"

file 2:
run();
function run()
{
   require_once 'file 1';
   require_once 'file 3';
}

file 3:
crashout();
function crashout()
{
  require_once 'file 1';
  if( isset($A) )
    echo "this will never happen!";
  else
    echo "PHP will claim that A is not set, even though"
      . " it is explicit set in the file that is explicitly included above!";
}

I bashed my head against a wall with this (kind of) problem until I realised what was going on: PHP has a very poor definition of “a file has already been included”.

And what the heck can you do to workaround this? Actually, I’m not sure yet. I’ve only recently worked out how and why the runtime does what it does. I’ve not yet worked out a simple approach to PHP programming that avoids the above problems, beyond “never use an include* statement from within a function – never ever, under any circumstances”. At least that forces the behaviour to be predictable (NB: as soon as you do an include* from within a function, each and every one of your PHP scripts will potentially cease to work). But it’s very annoying to be actively prevented from ever doing an INC/INT/EXT.

NB: this was more a quick-and-dirty practice exercise than a serious attempt at a CAPTCHA. I don’t believe in CAPTCHAs, generally – but if you ARE going to use them, it’s best to have a lot of them in the wild, so it’s harder for crackers to do “crack once, spam everywhere”. See the section at the bottom for links to suggestions for other people’s CAPTCHAs that I reckon would be better for production use if you can get them to work :).

Most CAPTCHAs are breakable in under 10 minutes. Personally, I can break nearly every single one I’ve seen (there are a few exceptions, but then you just start hiring bored students etc to mass-crack them for you, by hand). Every now and then I have a go with new ones to prove to myself they’re still easy to break. They generally are.

So, I know none of this is perfect, but I wanted a minimum of:

1. Implemented in PHP
2. Highly effective at preventing plain simple automated attacks based on command-line scripts that I could write in under 5 minutes
3. Doesn’t upset the user / take a long time to process / too hard for humans
4. Doesn’t look ugly
5. Simple and quick to integrate with my app
6. Doesn’t use any external libraries unless those libs are already available as Debian pre-compiled packages

I found a simple idea based on asking humans to rate photos, from a guy called David Spiral, which I rather liked. Nice ideas there. If you never shared this code with anyone, it might work. Unfortunately he’d made a beginner’s mistake and encoded the ID of the “correct” answer in the source code of the HTML page as a “hidden” HTML fom field. Ahem. That took about 5 seconds even for a moronic spammer to crack (HTML source based cracks are easy, and some crack tools / rootkits will even try to automatically (!) discover them for you).

Likewise, he’d implemented a secondary secret algorithm which identified all the images as being incorrect by having an even random ID, or correct by having an odd random ID. That took about 30 seconds to notice and crack without even reading the PHP source (although reading the source confirmed it immediately). Again, I believe there are multiple script kiddie tools that would automatically break this for you, as a spammer. They generally cost something like $20 each to license. A pittance.

After a couple of minutes of thinking and fiddling, I modified his code to replace those two freebies with secrets that are meaningless to the client. The server can still do the one-way check of whether the user submitted the “correct” answer, but at least now the user has to guess it :).

I also made some minor cosmetic changes (e.g. drawing the images in a grid instead of a line, and making the images themselves clickable instead of having to hit the radio buttons).

David has peppered his source with “(c)Copyright” himself etc, which I am not a fan of for such a trivially small example, so I’ve re-implemented it from scratch, and here it is public domain. Do with it what you will.

(but, just to be clear, I do like David’s approach and code, and he did – as he promised – comment it nice and clearly. Thanks, David)

Install / usage instructions

1. save these 4 PHP files somewhere
2. edit “secure.php” and change the SALT to a random alphanumeric string of your choice (it doesn’t matter what it is so long as you don’t share it with other people)
3. create a sub-directory called “folders” and put two images inside, named “cat.jpg” and “dog.jpg”
4. run index.php to see the captcha in action

To use this in your own application, it ought to be very easy to see how you can “require_once” the index.php file into your own forms (personally I would rename it to something like “captcha-generator.php” once you’ve finished testing it, simply for convenience), and correspondingly insert the process.php (again, rename the file first) inside your form-processing script(s).

Suggestions for improvement:

1. include a timestamp in the secret value so that the form cannot be captured and replayed infinitely
   • NB: at the moment this is a fatal flaw in the code – replay attacks are *another* built-in feature of the cracking tools
2. change the image-fetch to instead grab randomized images from images.google.com using hard-coded search-terms
   • this has the benefit that it’s impossible to simply download all the images and save them for comparison/replay attacks – assuming you choose search terms that change frequently
   • I’d prefer to use flickr tagstreams for this, but IIRC that kind of embedding might be against flickr terms of service
   • …and surely someone else has already done this with flickr, but I couldn’t remember what the project was called. I found this one at PlanetJoel, but the site kept timing out when I tried to get it. (this broke one of my cardinal requirements: that the CAPTCHA be quick and easy for human users – but I might go with the planetjoel one anyway when I move my project to production)

PS…

I’m very jetlagged right now. I might well have done something really stupid here that invalidates the whole purpose :). Really … check this for yourself, carefully, and think about what it’s doing and why!

FILE: index.php

<?php
require_once "secure.php";

define('GRIDSIZE', 3);

$numimages = GRIDSIZE * GRIDSIZE;

$index = rand(1, $numimages);
$secret = hashSpecialImageNumber($index);

if( SALT == 'YOUDIDNTCHANGETHIS' )
{
	?>
	<h2>ERROR: Install incomplete</h2>
	<P>
	OK, you did something really stupid: you ignored the one-line install
	instructions, and tried to run this code with the core security part
	disabled
	</P>
	<P>
	To save you from your own ignorance, I'm not going to let the code run
	until you do what you were supposed to, i.e. edit the secure.php file
	and change the value of SALT to some random string of numbers and letters
	</P>
	<P>
	The current value is:
	</P>
	<blockquote>
	<?php echo SALT; ?>
	</blockquote>
	<?php
}
else
{
echo "<form name='captcha' method=\"POST\" action=\"process.php\">";

echo "<table>";
	for ($i = 1; $i <= $numimages; $i++)
	{
		if( $i % GRIDSIZE == 1 )
		{
			echo "<tr>";
		}
		echo "<td align=\"center\">";

		$iless = $i - 1;
		echo "<img src=\"image.php?secret=${secret}&n=$i\"";
		echo "onclick=\"document.forms['captcha'].selectedindex[$iless].checked=true\">";
		echo "<br>\n";
		echo "<input type=\"radio\" name=\"selectedindex\" value=\"$i\" \>\n";

		echo "</td>";		

		if( $i % GRIDSIZE == 0 )
		{
			echo "</tr>";
		}
	}

echo "</tr></table>";

echo "<input type=\"hidden\" name=\"secret\" value=\"".$secret."\" \>";

echo "<input type=\"submit\" \>";

echo "</form>";
}?>

FILE: secure.php

<?php
define('SALT', 'YOUDIDNTCHANGETHIS' );
function hashSpecialImageNumber( $num )
{
	return md5( SALT . $num );
}

function checkSpecialImageNumber( $num, $hash )
{
	return md5( SALT . $num ) == $hash;
}
?>

FILE: image.php

<?php
require_once "secure.php";

define('STANDARD_IMAGE','images/dog.jpg');	// modify as required to suit your own images
define('SPECIAL_IMAGE','images/cat.jpg');	// modify as required to suit your own images

header('Content-Type: image/jpg');

if( checkSpecialImageNumber($_GET['n'], $_GET['secret']) )
{
	exit( readfile( SPECIAL_IMAGE ) ); // quit processing after serving the Special image
}
else
{
	exit( readfile( STANDARD_IMAGE ) ); // quit processing after serving the Standard image
}
?>

FILE: process.php

<?php
require_once "secure.php";

// Compare selected image with special image number to see if correct image was selected

$input = $_REQUEST['selectedindex']; // Number of image selected on form

$secret = $_REQUEST['secret']; // Obscured Number of special image from form

if( checkSpecialImageNumber($input, $secret) )
{
	// Your "Passed validation" code here

}
else
{
	echo "<H1>FAIL</H1>";
	echo "input number = $input<p>";
	echo "special = $secret<P>";
	echo "hash = ".hashSpecialImageNumber( $input )."<P>";
	echo "checkSpecial = ". checkSpecialImageNumber( $input, $secret )."<P>";
}
?>

After much trial and error, here’s one that *actually works*:

// Missing feature (?) from MySQL: find the list of valid ENUM values for a given ENUM
// (actually, returns all the value-arrays for ALL the enum fields in a given table, by name)
// ---------------------------------------------------------
function fetchEnumValuesForTable( $tablename )
{
	global $db; // assuming you're using PEAR:DB here, and throughout (I use it, or MDB, exclusively)

	$enumresult = $db->query("SHOW COLUMNS FROM $tablename");

	// Makes arrays out of all ENUM type fields.
	// Uses the field names as array names and skips non-ENUM fields
	while( $enumrow = $enumresult->fetchRow() )
	{
		extract($enumrow);
		if (substr($Type, 0, 4) != 'enum') continue;

		$Type = str_replace('enum', 'array', $Type);

		// Add to array
		eval( '$tmp = '."$Type;" ); // I'm not sure why, but I had to do this
		// intermediate step to get it to work

		$results[$Field] = $tmp;
	}

	return $results; // returns an array mapping each enum's "column name"
	// to "array of elements valid fo that ENUM"
}