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.
Utilisation des variables super-globales
Cette fonctionnalité est OBSOLETE depuis PHP 5.3.0 et a été SUPPRIMEE depuis PHP 6.0.0. Nous vous encourageons vivement à ne plus l'utiliser.
L'une des évolutions les plus controversées de PHP a été le changement de valeur par défaut de la directive PHP register_globals, qui est passée de On à Off en PHP » 4.2.0. Beaucoup d'applications dépendaient de cette directive, et de nombreux programmeurs ne savaient même pas qu'elle existait, et supposait que c'était le fonctionnement normal de PHP. Cette page explique comment on peut écrire du code peu sécuritaire en utilisant cette directive. Gardez bien en tête que cette directive, par elle-même, n'est pas un trou de sécurité, mais qu'elle facilite leur création.
Lorsqu'elle est activée, register_globals va injecter vos scripts avec toutes sortes de variables, comme les variables issues des formulaires HTML. Ceci, couplé au fait que PHP ne requiert pas d'initialisation de variable signifie que la programmation de script peu sûr est possible. Ce fut une décision difficile de la communauté PHP, mais finalement, il a été décidé de désactiver par défaut cette variable. Lorsqu'elle est active, le programmeur ne sait pas exactement d'où provient le contenu de la variable, et ne peut que faire des suppositions. Les variables internes définies dans le script sont mélangées avec les données envoyées par les utilisateurs, et en désactivant register_globals, on empêche cela. Voyons avec un exemple le fonctionnement de register_globals :
Exemple #1 Exemple de mauvaise utilisation de register_globals
<?php
// $authorized = true uniquement si l'utilisateur est identifié
if (authenticated_user()) {
$authorized = true;
}
// Comme nous n'avons pas initialisé $authorized avec false, cette dernière
// peut être définie via register_globals, comme avec l'URL GET auth.php?authorized=1
// Tout le monde peut facilement être reconnu comme identifié!
if ($authorized) {
include "/donnees/critiques/data.php";
}
?>
Lorsque register_globals est activé, la logique ci-dessus peut être prise en défaut. Lorsque register_globals est désactivée $authorized ne peut plus être assignée via la requête, et le script est maintenant sûr, même s'il reste recommandé de toujours initialiser ses variables. Par exemple, dans notre programme ci-dessus, nous pourrions ajouter $authorized = false. En faisant cela, le script peut fonctionner avec register_globals on ou off, car les utilisateurs seront par défaut non-identifiés.
Un autre exemple implique les sessions. Lorsque register_globals est activé, on peut aussi utiliser $username dans notre exemple, mais, encore une fois, vous devez garder en tête que $username peut aussi provenir d'autres biais, tels que GET (via l'URL).
Exemple #2 Exemple d'abus de sessions avec register_globals on ou off
<?php
// Nous ne savons pas d'où provient $username mais nous savons que
// $_SESSION contient les données de session
if (isset($_SESSION['username'])) {
echo "Bonjour <strong>{$_SESSION['username']}</strong>";
} else {
echo "Bonjour <strong>visiteur</strong><br />";
echo "Voulez-vous vous identifier?";
}
?>
Il est même possible de prendre des mesures préventives, pour être alerté lorsqu'une tentative d'usurpation est faite. Si vous savez à l'avance de quelle variable le nom d'utilisateur doit provenir, vous pouvez vérifier si les données que vous manipulez sont d'une origine contrôlée. Même si cela ne garantit pas que les données ne puissent être falsifiées, cela complique la tache du faussaire. Si vous ne vous préoccupez pas de l'origine des données, vous pouvez utiliser la variable $_REQUEST qui contient un mélange de données GET, POST et COOKIE. Voyez aussi la section du manuel concernant les variables de sources externes à PHP.
Exemple #3 Détection simple de fausses variables
<?php
if (isset($_COOKIE['MAGIC_COOKIE'])) {
// MAGIC_COOKIE provient d'un cookie.
// Assurez-vous de valider les données du cookie!
} elseif (isset($_GET['MAGIC_COOKIE']) || isset($_POST['MAGIC_COOKIE'])) {
mail("admin@example.com", "Tentative possible d'attaque", $_SERVER['REMOTE_ADDR']);
echo "Alerte sécurité, l'admin a été prévenu.";
exit;
} else {
// MAGIC_COOKIE ne provient pas de REQUEST
}
?>
Bien sur, désactiver l'option register_globals ne signifie pas que votre code est sécuritaire. Pour chaque donnée reçu, vous devez appliquer un maximum de validations. Vérifiez toujours les données de votre visiteur, et initialisez vos variables! Pour vérifier les variables non-initialisées, voyez la fonction error_reporting(), qui peut afficher les erreurs de niveau E_NOTICE.
Pour des informations sur l'émulation de register_globals On ou Off, voyez la FAQ.
Note: Superglobales : disponibilité
Depuis PHP 4.1.0, les tableaux superglobaux tels que $_GET, $_POST et $_SERVER, etc. sont disponibles. Pour plus d'informations, lisez la section superglobals
Utilisation des variables super-globales
15-Jan-2009 03:52
19-Nov-2008 01:38
your webspace provider has register-globals activated by standard and you don't have a chance to turn it off? no problem anymore, here is your solution...
<?php
// ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
// this is just a workaround to kill all through register globals imported vars!
// ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
// place this script after session_start() to be sure you unregister_globals('_SESSION');
// that's all, now all through "register_globals" assigned vars are deleted from scope.
// ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
if (ini_get('register_globals') == 1)
{
if (is_array($_REQUEST)) foreach(array_keys($_REQUEST) as $var_to_kill) unset($$var_to_kill);
if (is_array($_SESSION)) foreach(array_keys($_SESSION) as $var_to_kill) unset($$var_to_kill);
if (is_array($_SERVER)) foreach(array_keys($_SERVER) as $var_to_kill) unset($$var_to_kill);
unset($var_to_kill);
}
?>
hope you like it ;)
greetz subarea
27-Oct-2008 11:21
BEWARE of using register_globals = On, it's not only bad karma but highly dangerous.
Consider the following coding:
<?php
// assume $_SESSION['user'] = array('Hello', 'World');
// assume session_start() was called somewhere before.
print('<pre>Contents of array $_SESSION[\'user\']');
print_r($_SESSION['user']);
print('<hr>Contents of array $user (PHP SETUP register_globals = On)');
print_r($user);
print('</pre>');
?>
If you manipulate $user you'll manipulate $_SESSION['user'] as well with PHP SETUP register_globals = On.
So please avoid it at any cost, no serious programmer would ever want to have register_globals = On.
01-Sep-2008 12:39
<?php
// Unregister_globals: unsets all global variables set from a superglobal array
// --------------------
// This is useful if you don't know the configuration of PHP on the server the application
// will be run
// Place this in the first lines of all of your scripts
// Don't forget that the register_global of $_SESSION is done after session_start() so after
// each session_start() put a unregister_globals('_SESSION');
function unregister_globals()
{
if (!ini_get('register_globals'))
{
return false;
}
foreach (func_get_args() as $name)
{
foreach ($GLOBALS[$name] as $key=>$value)
{
if (isset($GLOBALS[$key]))
unset($GLOBALS[$key]);
}
}
}
unregister_globals('_POST', '_GET', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES');
?>
14-Jul-2008 11:19
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).
<?php
//Undo register_globals
function unregister_globals() {
if (ini_get('register_globals')) {
$array = array('_REQUEST', '_FILES');
foreach ($array as $value) {
if(isset($GLOBALS[$value])){
foreach ($GLOBALS[$value] as $key => $var) {
if (isset($GLOBALS[$key]) && $var === $GLOBALS[$key]) {
//echo 'found '.$key.' = '.$var.' in $'.$value."\n";
unset($GLOBALS[$key]);
}
}
}
}
}
}
?>
The echo was for debuging, thought it might come in handy.
16-Apr-2008 10:59
For my application I defined two functions:
wit_set_gv('space','key','value')
wit_get_gv('space','key')
Forgive the "wit_" prefix but the gv stays for Global Variable.
Maybe I should start with a simple version:
wit_set_gv('key','value')
wit_get_gv('key')
This way you would set or get a global/session value.
The register_globals (on or off), session state and/or
superglobal variables will be handled by these functions.
I did add a 'space' item because I wanted to have control
on what goes to/comes from where. As an example if I call:
wit_get_gv('WIT_CONF','URL')
I know that I have to check for a global variable named
WIT_CONF which also gives me a positive responce
on isset($WIT_CONF['URL']). In this case $WIT_CONF
is global and static. But I can also set up a $WIT_STATE
variable which will represent the state of the transaction.
Using the code of WIT_set_gv() and WIT_get_gv(), with the help
of a simple few lines (in my case: include globals.inc.php)
definition script I handle this problem.
In my case, for example, if 'WIT_STATE' (or other names)
is not a defined globally available variable I default to check
for a session variable.
For example you might warn or stop if a requested named variable
matches a $_POST, $_GET or $_SESSION variable name while you
do not expect so. i.e. all my private data has a wit_ prefix
but no public request has (shouldn't have) this prefix.
Oopss. I do realize that this comment might not be in the proper
place. i.e. "register_globals". Indeed it might give some advice
to users still using register_globals and willing to change the
code for a "better" solution. Of course the simple switching to "register_globals = off" might not solve
the securities issues.
Cheers
F
16-Apr-2008 07:46
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.
<?php
//Undo register_globals
function unregister_globals() {
if (ini_get(register_globals)) {
$array = array('_REQUEST', '_SESSION', '_SERVER', '_ENV', '_FILES');
foreach ($array as $value) {
foreach ($GLOBALS[$value] as $key => $var) {
if ($var === $GLOBALS[$key]) {
unset($GLOBALS[$key]);
}
}
}
}
}
?>
01-Apr-2008 04:59
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.
No problem, just call (below defined):
<?php register_globals(); ?>
anywhere, as often as you want. Or update your scripts!
<?php
/**
* function to emulate the register_globals setting in PHP
* for all of those diehard fans of possibly harmful PHP settings :-)
* @author Ruquay K Calloway
* @param string $order order in which to register the globals, e.g. 'egpcs' for default
*/
function register_globals($order = 'egpcs')
{
// define a subroutine
if(!function_exists('register_global_array'))
{
function register_global_array(array $superglobal)
{
foreach($superglobal as $varname => $value)
{
global $$varname;
$$varname = $value;
}
}
}
$order = explode("\r\n", trim(chunk_split($order, 1)));
foreach($order as $k)
{
switch(strtolower($k))
{
case 'e': register_global_array($_ENV); break;
case 'g': register_global_array($_GET); break;
case 'p': register_global_array($_POST); break;
case 'c': register_global_array($_COOKIE); break;
case 's': register_global_array($_SERVER); break;
}
}
}
?>
13-Dec-2007 03:50
In addition to Mike Willbanks post:
Put this to the beginning of every file or to a functions.inc.php and call it every time before start working with user variables.
This will prevent problems with wrong initalized variables or users who try to break your application.
And this has an extra bonus: Applications which still work are also register_globasl = off enabled!
<?php
//
// If register_globals is on, delete all variables exept the ones in the array
//
if (ini_get('register_globals')) {
foreach ($GLOBALS as $int_temp_name => $int_temp_value) {
if (!in_array($int_temp_name, array (
'GLOBALS',
'_FILES',
'_REQUEST',
'_COOKIE',
'_SERVER',
'_ENV',
'_SESSION',
ini_get('session.name'),
'int_temp_name',
'int_temp_value'
))) {
unset ($GLOBALS[$int_temp_name]);
}
}
}
//
// Now, (re)import the variables
//
if (isset ($_REQUEST['pass']))
$ext_pass = $_REQUEST['pass'];
if (isset ($_REQUEST['user']))
$ext_user = $_REQUEST['user'];
if (isset ($_REQUEST['action']))
$ext_action = $_REQUEST['action'];
//
// Cleanup entries
//
$int_pass = (isset ($ext_pass) ? preg_replace("'[^A-Z]'", "", $ext_pass) : '');
$int_user = (isset ($ext_user) ? preg_replace("'[]A-Za-z0-9áäàâãëèéêïìîóöòôõúüùû \.^\$\!\_-()'", "", $ext_user) : '');
$int_action = (isset ($ext_action) ? intval($ext_action) : '');
//
// Import Session variables
//
if (isset ($_SESSION)) {
foreach ($_SESSION as $int_temp_key => $int_temp_value) {
if ($int_temp_value != '') {
$$int_temp_key = $int_temp_value;
}
}
}
//
// Import Cookie variables
//
if (isset ($_COOKIE)) {
foreach ($_COOKIE as $int_temp_key => $int_temp_value) {
if ($int_temp_value != '') {
$$int_temp_key = $int_temp_value;
}
}
}
//
// From here on, work only with $int_ variables and you're safe!
//
?>
With this you can prevent a lot of different problems!
20-Jul-2007 06:08
Useful for shared hosting or scripts that you are sharing with other people.
<?php
// Effectively turn off dangerous register_globals without having to edit php.ini
if (ini_get(register_globals)) // If register_globals is enabled
{ // Unset $_GET keys
foreach ($_GET as $get_key => $get_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $get_key)) eval("unset(\${$get_key});");
} // Unset $_POST keys
foreach ($_POST as $post_key => $post_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $post_key)) eval("unset(\${$post_key});");
} // Unset $_REQUEST keys
foreach ($_REQUEST as $request_key => $request_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $request_key)) eval("unset(\${$request_key});");
}
}
?>
18-Dec-2003 08:38
import_request_variables() has a good solution to part of this problem - add a prefix to all imported variables, thus almost eliminating the factor of overriding internal variables through requests. you should still check data, but adding a prefix to imports is a start.
