comme je l'indique, coder pour register globals = OFF c'est rattraper plus de 10 ans de non évolution du code.
De plus ce paramètre est supprimé depuis la version 5.4 et c’est un paris sur l'avenir car les hébergeurs y viennent et en dehors d'avoir un serveur perso tu n'auras pas le choix
Je sais que c'est galère et que tu va y passer du temps, rien que pour savoir d'où provient une variable (c'est du vécu) mais à ce prix ton code sera au moins lisible et précis.
Ensuite pour le coté sécurisation, il faut que tu comprenne bien ce que fait le register globals = on
Avec ce paramètre toutes les variables issue de formulaire ($_GET ou POST), de l'url ($_GET), de cookie ($_COOKIE), session ($_SESSION), serveur ($_SERVER) etc sont déclarées directement dans le code.
donc une valeur passer dans l'url, disons
http://tonsiteatoi.com?login=412
va donner dans le code une variable $login(qui aura pour valeur 412).
Maintenant imagine que tu ai une variable de session qui s'appel truc.
à la version ante diluvienne tu aurais ce code
<?php
session_start();
session_register('login');
$login= 412;
?>
ce qui correspond, en utilisant les supers globales à
<?php
session_start();
$_SESSION['login'] = 412
?>
donc si l'on arrive sur une page qui vérifie qu'un membre est connecté tu as un code qui peux ressembler à ça
<?php
session_start();
if(!$login) { // on est d'accord à ne pas faire il faut utiliser isset ou empty, mais c'est malheureusement souvent le cas ....
echo 'faut être connecté oust, du balai';
}
else {
echo 'coucou le membre : '.$login;
}
?>
donc avec ce code et les lignes du dessus tu te rend compte que le mec qui est connecté va afficher ce qu'il y a dans le else, mais aussi le mec qui met dans l'url ?login=xxx.
Maintenant imagine sur un forum comme ici, et que login correspond à l'id de l'utilisateur dans la table sql qui va bien. Tu affiche le profile d'un membre, de préférence un administrateur, tu affiche les pages d'administration juste en mettant ?login=l'id de l'admin.
==> tu a créé une faille de sécurité.
Autre chose, la collision des variables.
si tu as oublié que tu a une variable de session email et que dans un formulaire de contact (par exemple) tu demande d'entrer un email, dans un champs texte qui s'appel email. A la validation comment peux tu être certain de ce que va contenir $email ?
pour cela il y a un paramètre
variable_order qui indique l'ordre de création des variables et donc d'écréasement puisse qu'elle auront le même nom.
Par défaut c'est EGPCS pour (ENV ,GET, POST, COOKIE et SERVER). L'ordre est important car il s'agit de l'ordre dans lequel les variables seront créer.
du coup si tu as une variable en get elle sera écrasée par une du même nom en post, qui peux être écrasée par une du même nom en cookie etc .
au final du n'aura surement pas la valeur que tu souhaite.
Ensuite les problème de ce genre peuvent aussi être du à d'autre chose comme un formulaire d'upload qui laisse passer n'importe quoi, un formulaire de connexion qui ne controle pas les données et n'échappe aucune valeur du coup tu crée une faille de type injection SQL (cf google).
Donc au final récupère ton code sur ta machine, configure php pour register globals =
PHP (si php < 5.4 sinon c'est pas défaut) et corrige ton code.
bon courage.
@+
Il en faut peu pour être heureux ......
