Le troisième lien dans google avec la requete REGISTER GLOBAL sécurité nous indique le lien suivant.
Voici son contenu qui est à mon goût assez explicite :
Variables auto-déclarées : Pourquoi c'est mal ?
Une caractéristique qui a fait le bonheur de nombreux développeurs PHP est la déclaration automatique des variables. Mais les temps changent et désormais, il est recommandé de ne pas utiliser cette fonctionnalité !
On parle de quoi là ?
Vous savez, lorsque vous créez par exemple un cookie dont le nom est "utilisateur", sur toutes les pages de votre site, vous pouvez utiliser directement la variable $utilisateur qui est automatiquement créée par PHP à l'initialisation du script. Il en va de même pour les données transmises dans les liens, les formulaires ou les sessions. C'est très pratique, et surtout extrêmement simple à utiliser.
Cette fonctionnalité qui existe depuis la création de PHP est actuellement remis en cause et désormais le paramètre de configuration "register_globals" est à "off". Cela implique que les variables ne sont plus déclarées automatiquement et vous devez accéder aux tableaux $_GET, $_POST, $_COOKIE, $_SESSION, etc. afin de traiter vos données.
Pourquoi avoir fait une telle chose ?
Tout simplement à cause de notre bêtise ! Oui, vous .. moi .. nous tous avons usé et abusé par le passé de cette fonctionnalité sans toujours trop réfléchir, et nous avons engendré des anomalies et autres trous de sécurité par manque de discernement !
Heu .. je ne comprends pas bien là !
Si je fais "echo $utilisateur;", d'où vient cette variable ? De la session ? D'un formulaire ? D'un cookie ? C'est une variable locale ? En fait, rien ne permet de connaître sont origine et si par distraction, vous partez par exemple du postulat que votre variable est locale, vous risquez de bien mauvaises surprises.
Voici un petit exemple. En voulant bien faire, on a séparé la partie traitement de la partie présentation, ce qui nous donne ceci :
admin.php
Code :
- <?php
- if( $login == 'admin' and $pass == 'passadmin' ) {
- $admin = true;
- } else {
- $admin = false;
- }
- require 'affichage/affichage.inc.php';
- ?>
|
affichage.inc.php (dans un répertoire "affichage" protégé par un .htaccess, mais on a oublié de le mettre !)
Code :
- <?php
- if( $admin == true ) {
- echo 'Phrase secrète réservée à l\'administrateur';
- }
- ?>
|
Dans cette situation, si on utilise l'URL suivante :
http://www.monsite.com/affichage/a [...] hp?admin=1
La phrase secrète s'affiche !
Cela peut vous paraître trivial, mais de nombreux trous de sécurité étaient basés sur ce principe.
En fait, register_globals à "on" n'est pas un trou de sécurité, mais il les favorise si l'on n'est pas attentif.
Le danger est d'autant plus grand avec les sessions car normalement, l'utilisateur ne peut pas modifier leur contenu. Dans le cas de pages réservées aux membres, au lieu de redemander l'identifiant et le mot de passe à chaque fois, on place une donnée en session indiquant que la personne est authentifiée. Seulement, si on n'utilise pas le tableau $_SESSION, mais directement une variable auto-déclarée, vous vous exposez au risque qu'un utilisateur déclare cette donnée dans l'URL de la page.
C'est très pénible de devoir écrire $_SESSION['xxxx'] !
Oui, mais disons que c'est pour notre bien et aussi parce que nous l'avons bien cherché en développant des scripts bourrés de fautes d'inattention.
Si je dois changer mes vieux scripts, je vais avoir trop de boulot !
Je suis entièrement d'accord avec vous, mais ce n'est pas une raison pour continuer les nouveaux développements avec les variables auto-déclarées. Laissez le register_globals à "on" pour que vos vieux scripts fonctionnent encore, mais faites comme s'il était à "off".
Note : Pas trouvé de copyright sur cette article...
Message édité par yoyo354 le 30-04-2005 à 13:17:56
---------------
http://yoyo.eurotchat.net -> Wednesday 14 September a 02:00:01 up 43 days, 11:47, 2 users, load average: 0.07, 0.03, 0.00
.
.
