Vous l'avez remarqué, la plupart des problemes de compatibilité de php3 à php4 viennent de cette nouvelle configuration de PHP par défaut.

Quand vous posez la question, on vous répond:

Pour des raisons de sécurité évidentes, [NDLR: pas pour tout le monde!] register_globals est maintenant à OFF
Va voir la FAQ!

C'est assez frustrant et nombre d'entre vous ont demandé quelles étaient ces fameuses raisons de sécurité. Je vais donc donner un simple exemple (un cas pratique).

Vous avez une page d'administration, que vous devez donc absolument protéger par mot de passe, vous ne voulez pas passer par .htaccess (pour des raisons d'esthétisme, ou de serveur, ou je ne sais quoi).

Avec register_globals as ON

Vous avez une liste d'utilisateurs, dont certains sont administrateurs. Très simplement, votre page d'identification ressemble à ça:

<?php
// $user et $pass viennent d'un formulaire
session_start();
if (mot_de_pass_ok($user, $pass)) {
	$login = 1;
	session_register('login');
	if (is_admin($user)) {
		$admin = 1;
		session_register('admin');
	}
}
// on met un message en fonction de l'identification
...
?>

Et dans la page d'administration:

<?php
session_start();
if (!$admin) {
	// on téléporte l'utilisateur ailleur !
	header("Location: 403_forbidden.html");
	exit;
}
?>
<h1>Administration</h1>
...

On n'accède a cette page que si on s'est identifié comme administrateur dans la page d'identification précédente.
Ça a l'air propre, et pour preuve ça marche! Vous arrivez à administrer votre page, et ceux qui n'ont pas les droit - eux - n'y arrivent pas.

Ce que vous n'aviez pas prévu, c'est qu'un pseudo-pirate, un hacker de bas étage (allez, 14 ans grand max) a deviné votre méthode, et qu'il sait qu'il n'a qu'à modifié la variable 'admin' pour être vu comme administrateur par le site. Mais il ne peut pas le faire, c'est une variable de session ?!
Et bien si ! Il n'a qu'à se rendre sur http//votresite.com/administration.php?admin=1
Le script voit donc la variable $admin comme valant 1, et reconnait le visiteur comme administrateur. Trop facile, il peut maintenant supprimer les news, virer des pages, des utilisateurs, etc... effrayant non ?


Avec register_globals a OFF

Dans ce deuxieme cas, vous devez spécifier l'origine d'une variable.
Le code deviendra donc:

<?php
// $user et $pass viennent d'un formulaire
session_start();
if (mot_de_pass_ok($user, $pass)) {
	$_SESSION['login'] = 1;
	if (is_admin($user)) {
		$_SESSION['admin'] = 1;
	}
}
// on met un message en fonction de l'identification
...
?>

Dans la page d'administration:

<?php
session_start();
if (!$_SESSION['admin']) {

	// on téléporte l'utilisateur ailleur !
	header("Location: 403_forbidden.html");
	exit;
} 
?> 
<h1>Administration</h1> 
...

On n'a pas modifié grand-chose... Et pourtant maintenant la variable $_SESSION['admin'] ne peut etre confondue avec aucune autre variable, et quoique fasse le visiteur, il faut que la variable de session soit définie PAR VOUS quelque part.
Plus aucun risque de piratage de ce coté la. Et c'est rassurant.


Conclusion

Le problème principal quand register_globals est à ON, c'est qu'on ne connait pas la provenance d'une variable (url, formulaire, cookie, session, etc...). Les conséquences de cette méconnaissance sont parfois extrèmement facheuses.

La morale de cette histoire est la suivante:

Ne mettez pas register_globals à ON sous prétexte que le script marche mieux comme ça.
Car cela constitue un trou de sécurité en soi !!

Cependant, utiliser les variables $_SESSION, $_COOKIE, $_FILES, etc... fonctionne même quand register_globals est à ON. Ne vous en privez pas!

Auteur original: naholyr

À partir de PHP 4.1.0: import_request_variables(), même si utiliser une telle fonction est généralement une mauvaise idée. Cette fonction d'ailleurs génère une Notice à ce sujet, voir le manuel.