What Are Register_Globals in PHP

Why is REGISTER_GLOBALS so bad?

REGISTER_GLOBALS means that all variables passed through GET or POST are avilable as global variables in your script. Since accessing undeclared variables is not an error in PHP (it's a warning), it can lead to very nasty situations. Consider this, for example:

<?php
// $debug = true;
if ($debug) {
echo "query: $query\n";
}

It is not a bad thing per se (well engineered code should not generate warnings, therefore should not access any variables that might be undeclared (and should not need REGISTER_GLOBALS for the same reason)), but PHP code is usually [very] low quality, leading to this kind of security holes.

How can I emulate register_globals in PHP 5.4 or newer?

You can emulate register_globals by using extract in global scope:

extract($_REQUEST);

Or put it to independent function using global and variable variables

function globaling()
{
foreach ($_REQUEST as $key => $val)
{
global ${$key};
${$key} = $val;
}
}

If you have a released application and do not want to change anything in it, you can create globals.php file with

<?php
extract($_REQUEST);

then add auto_prepend_file directive to .htaccess (or in php.ini)

php_value auto_prepend_file ./globals.php

After this the code will be run on every call, and the application will work as though the old setting was in effect.

Is the PHP directive entry 'register_globals' has been completely removed from the php.ini(The PHP configuration file) as of PHP 7.1.12?

register_globals has been removed around PHP5.4, you an still simulate the behaviour but it is a bad practice.

You can emulate its behavior by adding a function call to a user-written register_globals() function like this:
https://pageconfig.com/post/register_globals-is-back-php-implementation

Or by prepending a user-written script to every executed php files, like this:
http://www.kaffeetalk.de/using-register_globals-in-php-5-5/

$HTTP_GET_VARS is called simply $_GET now, same for $POST, and most of the old $HTTP*_VARS has new names as well, most of the time it will only take a simple replace in path to migrate, but otherwise the whole structure got removed in PHP5.4:
http://php.net/manual/en/tutorial.useful.php

register_globals fix

If the code uses register globals, and hasn't been updated to not use it, then it was probably written a very long time ago. This means that:

  1. it's almost certain to have massive security holes;
  2. it likely uses other PHP functionality that's been deprecated and/or removed;
  3. it's probably very messy spaghetti code, and
  4. it's going to be a bitch to rewrite to fix all the issues.

My advice is to just find a modern shopping cart software package and help him set up his shop using that instead of trying to keep his existing ancient piece of software running. It may seem like more work, but it'll be a lot less hassle in the long run for everyone involved.

If you must fix up his existing code (ie if he begs you and offers to pay you a lot for the work), here's how to deal with register globals:

Register globals takes all the variables entered into the POST or GET arguments, and creates them as simple variables in the global namespace. So instead of $_GET['id'], you just get $id.

If the program is reasonably well written and documented, it may not be too hard to see what variables it is expecting. In that case, it's not to hard to sustitute $_REQUEST for the relevant variables; job done.

But a lot of (uh, most) old PHP code just throws global variables around without paying much attention to them. Throw in a bunch of includes, hundreds of lines of code without a function() declaration in site, and interwoven PHP and HTML code, possibly with some generate Javascript thrown in, and you often have a mess that is completely impenetrable to anyone except the original author (and sometimes not even them).

If the code looks like this, you will be a very brave man to attempt to repair it. You should just accept that it is unsalvageable, and walk away. I have had jobs in the past where I've been required to fix up old code like this, and trust me, you can sink months (or even years) of time into it before you start getting somewhere. In that kind of time scale, you might as well have written a whole new system from scratch.

register_globals exploit session array

Just tried site.php?_SESSION[logged]=1, and it works!

You can modify globals when register_globals is set to 1, using the GET method.

So yes, don't ever edit this option, if you're sure about it ;)

Dealing with register_globals

There are methods of dealing with register_globals described in the PHP manual. The register_globals ini setting can't be set at runtime by ini_set(), so if you can't do it with an .htaccess or web server configuration file, the method provided there would be the official workaround.

It basically provides this snippet of code to emulate compatibility:

<?php
// Emulate register_globals off
function unregister_GLOBALS()
{
if (!ini_get('register_globals')) {
return;
}

// Might want to change this perhaps to a nicer error
if (isset($_REQUEST['GLOBALS']) || isset($_FILES['GLOBALS'])) {
die('GLOBALS overwrite attempt detected');
}

// Variables that shouldn't be unset
$noUnset = array('GLOBALS', '_GET',
'_POST', '_COOKIE',
'_REQUEST', '_SERVER',
'_ENV', '_FILES');

$input = array_merge($_GET, $_POST,
$_COOKIE, $_SERVER,
$_ENV, $_FILES,
isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array());

foreach ($input as $k => $v) {
if (!in_array($k, $noUnset) && isset($GLOBALS[$k])) {
unset($GLOBALS[$k]);
}
}
}

unregister_GLOBALS();

?>

PHP newbie -- turning register_globals back on

php.net/...

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

Starting from PHP 5.4, register_globals has been deprecated.

Also, the right function to get ini settings is ini_get. So use ini_get('register_globals') to retreive the value.

Edit: I'm not sure what version of PHP you have.



Related Topics



Leave a reply



Submit