Using Register Globals

Warning

This feature has been
DEPRECATED as of PHP 5.3.0 and REMOVED
as of PHP 5.4.0.

Perhaps the most controversial change in PHP is when the default value
for the PHP directive
register_globals went from ON to OFF in PHP» 4.2.0. Reliance on this
directive was quite common and many people didn't even know it existed
and assumed it's just how PHP works. This page will explain how one can
write insecure code with this directive but keep in mind that the
directive itself isn't insecure but rather it's the misuse of it.

When on, register_globals will inject your scripts with all
sorts of variables, like request variables from HTML forms. This
coupled with the fact that PHP doesn't require variable initialization
means writing insecure code is that much easier. It was a difficult
decision, but the PHP community decided to disable this directive by
default. When on, people use variables yet really don't know for sure
where they come from and can only assume. Internal variables that are
defined in the script itself get mixed up with request data sent by
users and disabling register_globals changes this. Let's demonstrate
with an example misuse of register_globals:

// Because we didn't first initialize $authorized as false, this might be// defined through register_globals, like from GET auth.php?authorized=1// So, anyone can be seen as authenticated!if ($authorized) { include "/highly/sensitive/data.php";}?>

When register_globals = on, our logic above may be compromised. When
off, $authorized can't be set via request so it'll
be fine, although it really is generally a good programming practice to
initialize variables first. For example, in our example above we might
have first done $authorized = false. Doing this
first means our above code would work with register_globals on or off as
users by default would be unauthorized.

Another example is that of sessions.
When register_globals = on, we could also use
$username in our example below but again you must
realize that $username could also come from other
means, such as GET (through the URL).

Example #2 Example use of sessions with register_globals on or off

<?php// We wouldn't know where $username came from but do know $_SESSION is// for session dataif (isset($_SESSION['username'])) {

echo "Hello <b>{$_SESSION['username']}</b>";

} else {

echo "Hello <b>Guest</b><br />"; echo "Would you like to login?";

}?>

It's even possible to take preventative measures to warn when forging is
being attempted. If you know ahead of time exactly where a variable
should be coming from, you can check to see if the submitted data is
coming from an inappropriate kind of submission. While it doesn't
guarantee that data has not been forged, it does require an attacker to
guess the right kind of forging. If you don't care where the request
data comes from, you can use $_REQUEST as it contains
a mix of GET, POST and COOKIE data. See also the manual section on
using variables from external
sources.

Example #3 Detecting simple variable poisoning

<?phpif (isset($_COOKIE['MAGIC_COOKIE'])) {

// MAGIC_COOKIE comes from a cookie. // Be sure to validate the cookie data!

Of course, simply turning off register_globals does not mean your code
is secure. For every piece of data that is submitted, it should also be
checked in other ways. Always validate your user data and initialize
your variables! To check for uninitialized variables you may turn up
error_reporting() to show
E_NOTICE level errors.

For information about emulating register_globals being On or Off, see this FAQ.

To all those fans of this insecure functionality (which I'm glad is now turned off by default) , you can just use extract() to achieve a similar goal more securely (unless you overwrite local variables with $_GET or $_POST data).

Beware that all the solutions given in the comments below for emulating register_global being off are bogus, because they can destroy predefined variables you should not unset. For example, suppose that you have

<?php $_GET['_COOKIE'] == 'foo'; ?>

Then the simplistic solutions of the previous comments let you lose all the cookies registered in the superglobal "$_COOKIE"! (Note that in this situation, even with register_global set to "on", PHP is smart enough to not mess predefined variables such as $_COOKIE.)

A proper solution for emulating register_global being off is given in the FAQ, as stated in the documentation above.

/* Forces all GET and POST globals to register and be magically quoted. * This forced register_globals and magic_quotes_gpc both act as if * they were turned ON even if turned off in your php.ini file. * * Reason behind forcing register_globals and magic_quotes is for legacy * PHP scripts that need to run with PHP 5.4 and higher. PHP 5.4+ no longer * support register_globals and magic_quotes, which breaks legacy PHP code. * * This is used as a workaround, while you upgrade your PHP code, yet still * allows you to run in a PHP 5.4+ environment. * * Licenced under the GPLv2. Matt Kukowski Sept. 2013 */

I had a look at the post from Dice, in which he suggested the function unregister_globals(). It didn't seem to work - only tested php 4.4.8 and 5.2.1 - so I made some tweaking to get it running. (I had to use $GLOBALS due to the fact that $$name won't work with superglobals).

While we all appreciate the many helpful posts to get rid of register_globals, maybe you're one of those who just loves it. More likely, your boss says you just have to live with it because he thinks it's a great feature.

To expand on the nice bit of code Mike Willbanks wrote and Alexander tidied up, I turned the whole thing in a function that removes all the globals added by register_globals so it can be implemented in an included functions.php and doesn't litter the main pages too much.