PHP security guru Stefan Esser recently posted on some of the changes and important security issues that are likely to have significant effects for the everyday PHP coder (and user) with the release of the upcoming PHP 5.3.

Probably the simplest and most effective change that will come with PHP 5.3 is a modification to the way that $_REQUEST superglobal variables are handled. After several years of known vulnerability, it seems that the PHP developers are finally addressing one of the most risky elements of the scripting language.

For those who are unaware, the $_REQUEST superglobal variable in PHP is able to be called from anywhere in any PHP script, can not be overwritten/replaced by a user variable of the same name (though the contents can be changed) and is an associative array with the values passed via GET, POST and via cookie to the particular script ($_GET, $_POST, $_COOKIE PHP superglobals).

It took several years for the idea of disabling register_globals in the php.ini to be a default practice, and it is due to be removed from PHP 6.0 (if register_globals was enabled, any local variable could be overwritten by an equivalently named element of a superglobal array - $_GET['foo'] would overwrite $foo), but it still persists in odd corners of the Internet.

The difficulties associated with stamping out the register_globals directive are sure to be have been in the minds of the language developers when deciding to change the handling of $_REQUEST. As described by Esser, the primary change to $_REQUEST is a means to control what superglobals are looked at to form $_REQUEST, and in which order, without actually destroying or modifying the original superglobals. This means that $_REQUEST could be used to only monitor $_GET and $_POST submitted variables and ignore $_COOKIE values, or any other combination of the three.

Why not just get rid of $_REQUEST all-together, since $_GET, $_POST, and $_COOKIE already exist? Too many applications built in PHP are likely to use $_REQUEST in some form to enable a complete cutout of the superglobal. $_REQUEST does make the developer's life a little easier as they can accept user input from $_GET or $_POST without discrimination (though it is poor form to do so), but there are significant risks with allowing the user to arbitrarily overwrite values in either $_GET or $_POST.

Developing with a secure mindset means that all user-supplied data is considered potentially malicious, so it shouldn't really be a problem at the end of the day but using the relevant $_GET or $_POST superglobal vice $_REQUEST does make for better and more readable code.

Should developers continue to have access to risky functions, even when there are safer alternatives present in the core language? Some would argue that by not having the temptation in the first place, that the resultant software developed will be more secure by default, and that if developers really need access to a similar capability, they can code it themselves. Alternatively it could be argued that developers should be aware of their language of choice's limitations before attempting to code in it. Site after poorly coded site, project after poorly developed project, and sites such as the Daily WTF show that this is an extremely optimistic view to take, and one that is not borne out by reality.

In the future it is possible that $_REQUEST will go away completely, and developers should begin looking through their code to see what they can start doing now to make their code ready for future PHP versions, with the side benefit of making it more secure.