I once had a co-worker generate a unique user name from using the first two characters of an MD5 string and appending it to a First_Name_Last_Name string.

He kept wondering why there was unique user name collisions. He didn’t realize 2 positions and 16 hexadecimal values meant 2^16 coupled with a small name space (human names). And he thought it was somehow going to be more uniquely generated because it came from an MD5 hash as opposed to a random function.

I also once had a co-worker use recursion as a looping mechanism versus an iterative approach. He didn’t do it for elegance like for GCF, he did it for mundane looping purposes. He kept wondering why the Zend engine ran out of memory.

And I also knew a guy that used a switch statement on a boolean value. :-p

Had $include_path in the above code instead been defined as a constant, the attack would have failed because a constant can not be redefined within the execution of a script. So if line 1 was instead:

define(MY_INCLUDE_PATH, dirname(__FILE__));

and the require statements similarly updated to use the constant like:

require( MY_INCLUDE_PATH."/include/config.inc.php" );

Then this particular attack vector would have been closed. However it’s still bad form to use variable variables in this way as it just creates to many opportunities for a user to overwrite local variables. Basically if you’re doing that, you need to validate every variable for integrity in your script. It’s a lot more manageable to deal with (clean & validate) a hand full of known variables supplied by users than it is to do the same for every variable you use throughout your entire script.