bonjour,
 
je ne comprend pas pourquoi à chaque fois que l'on fait allusion à la securité, chacun parle de REGISTER GLOBAL ou lance un truc du genre "oui mais attention à regsiter global" etc...
naturellement j'ai essayé de me documenter sur ce truc mais pas de brève explicite ou consistante (google, php.net, ...).
j'ai juste comris que ce n'était pas une fonction, et que actuellement sur les serveurs il etait à OFF par defaut.    
 
en gros j'aimerai bien comprendre qu'est ce que c'est que cette spec. quoi  
 
merci  

+1, j'aimerais savoir moi aussi, je l'ai réactivé sur EasyPHP chez moi mais je ne vois pas à quoi celà peut servir .
Qu'il soit sur ON ou OFF, qu'est-ce que ça change au niveau de la sécurité ??
 
Bref, je suis ce topik .

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

affichage.inc.php (dans un répertoire "affichage" protégé par un .htaccess, mais on a oublié de le mettre !)

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...

Merci de ta réponse .
Je comprend mieux maintenant, j'ai utilisé les méthodes $_GET, $_POST, etc pour faire mon site, donc j'ai pas tort .
Merci encore de cet éclaircissement .

merci yoyo.    
j'avais essayé "securité register global", j'étais pas loin.
 
en gros, je crois comprendre que c'est pour identifier clairement la provenance d'une variable (session, cookie, url, formulaire, etc...). c'est ça?    
et le regsiter global à OFF nous oblige à quoi alors?
 
thx.
 
edit:
 
c'est bon j'ai tout compris.  

Si tu utilises la fonction $_REQUEST, ne serais-ce pas mieux ? (Tableau indifférent du type de requete...)

Et d'ailleurs coup de gueule contre les hébergeurs qui s'amusent à remettre register globals sur on

Ben Register Global = off, ca fait en sorte que (en très très résumé), si tu as une requete de type : http://monsite.com/mapage.php?mavariable=1, tu ne peux pas récupérer la variable mavariable sous la forme $mavariable, mais bien sous la forme $_GET['mavariable'], donc tu évites de faire des trous de sécurité dans tes scripts...

 
 
Le problème de request, quel est-il ? Imaginons qu'une variable de type GET et de type POST, dans la meme page , portent le meme nom, une des 2 n'existera plus . La , j'entend tout le monde me dire : "Mwahaha le noob il met le meme nom pour 2 trucs différents rentre chez ta mere va faire dla couture en moldavie" . Ok .
 
Mais certaines personnes ne savent pas bien nommer leurs variables, et puis, il est tellement plus agréable et simple de savoir d'ou vient une variable
 
par exemple :
 

 
ici, le $_REQUEST['id'] contiendra celui du post. Je voudrais donc alerter les personnes à propos de ce tableau qui selon moi est flou et qui peu vite devenir piegeant si l'ont a un code lourd avec un grand nombre de variable $_GET et $_POST

+1 ouais Bien diférrencier les deux

de ce coté la, ca va...  
le soucis viens du fait que les valeur des cookies et des variables de sessions sont overwritable vi le query string et la c'est nettement plus dangereux, d'autant que tout le monde est capable de modifier les paramètres dans l'url...

Et pourquoi ne pas utiliser simplement une variable <input type="hidden"> ?  
 
Pour moi, tu choisis, soit tu get, soit tu post, je ne vois pas l'intéret de mélanger les deux.