oxyd-x Posté 25 Août 2005 Partager Posté 25 Août 2005 Salut, je suis hébergé chez OVH, et ceux-ci, ne permettent pas la modification et le passage de register_globals sur "OFF". (sur un mutualisé;arff) Alors, je me retrouvre avec plein de questions ...niveau sécurité ! - les variables super-globals ( $_SERVER, $_ENV , ...) sont-elles concernées par la modification à la volé dans les urls ? si oui, éxiste-t-il un moyen de corriger ceci ? - le fait d'initialiser une variable $montest=null; est-il suffisant pour la protéger ? j'espere vraiment que quelqu'un pourra m'aider, parceque là, apres des heures de recherche sur le net (francais, bin oui, j'suis pas bilingue) je n'ai trouvé que des docs sur "comment passer à register_globals off" (mais pas de : comment etre emmerd... avec register_globals on )... enfin, merci pour votre aide ; ps: si par exemple, je veut obtenir l'adresse ip d'un visiteur $ip=null;$ip=$_SERVER['REMOTE_ADDR']; celle-ci peut-elle est modifié par le visiteur (je parle uniquement des register globals, pas des proxy, ...,...) Lien vers le commentaire Partager sur d’autres sites More sharing options...
minirop Posté 26 Août 2005 Partager Posté 26 Août 2005 le vrai problème avec les register global sur on c'est que si tu t'habitues a coder comme ca : <?phpmysql_query('INSERT INTO table VALUES('.$message.')');?> et que tu as un formulaire qui envoie cette valeur en hidden sur cette page, il suffira d'appeler page.php?message=hack (sans passer par le formulaire donc) pour mettre la valeur qu'on veux. (l'exemple est pourri mais j'ai pas trouver mieux) si tu utilises la syntaxe superglobale $_XXX[''], mais faut bien initialiser les autres variables car elles pourraient quand meme être modifiée via l'url (et utilise des nom assez zarb pour pas qu'on puisse les deviner facilement) voila Lien vers le commentaire Partager sur d’autres sites More sharing options...
TheRec Posté 26 Août 2005 Partager Posté 26 Août 2005 Bonjour, l'essentiel est de toujours vérifier la nature (le type) et le contenu des variables. Une bonne pratique pour ce faire est d'initialiser les variables que tu utilises, de cette manière même si l'utilisateur fournit une valeur par l'URL elle sera remplacée par celle qui tu souhaites, je parle des variables qui ne proviennent pas des utilisateurs. Par contre, pour les variables provenant des utilisateur, dans tous les cas possibles il faut limiter leur valeurs possibles au strict minimum. Si tu connais les valeurs qu'elle auront (par exemple un champ select), limite les possibilités à celles-ci. Si tu ne peux pas connaître leur valeur (par exemple un champ texte), vérifie le type, utilise (comme pour toutes autres variables) les fonctions d'échapement lors d'insertion dans la base, empêche l'utilisation des balises (X)HTML si elle ne sont pas nécessaires. Mais ces points sont plus relatifs à l'utilisation d'une base de données. Si tu utilises les tableaux de super-gloales ($_POST, $_GET, ...) tu n'auras pas ces problèmes (cités dans le 2ème paragraphe de ce message), mais ce que je t'ai cité plus haut sont des bonnes pratiques (à mon goût en tout cas) en programmation. Pour répondre à tes deux questions, certaines valeurs de $_SERVER peuvent être modifiés par l'utilisateur ($_SERVER['HTTP_USER_AGENT'] entre autres), mais cela demande plus qu'une simple modification d'URL. Ce n'est tout fois pas à négliger. Concernant $_ENV, les valeurs sont définies par le serveur et ce problème n'est donc pas important dans la mesure où si tu fais assez confiance au serveur pour héberger les sources de tes scripts tu devrais lui faire assez confiance pour gérer ses variables internes Le fait d'initialiser à null certaines variables peu résoudre certains problèmes mais l'exemple que tu cite n'est pas réellement un de ces cas. Le risque se situe surtout lorsque tu utilises une variable qui n'a pas été initialisée ou contrôlée tu risques d'avoir un contenu "malicieux" qui aura été fourni par l'utilisateur au moyen de l'URL. Le fait de l'initialiser à null n'a pas réellement de sens dans ton exemple vu que tu remplaces, tout de suite après, son contenu avec celui de la variable $_SERVER['REMOTE_ADDR']. P.S.: Il faut te dire avant tout que le mode register_globals depuis PHP4 a été conservé pour des raisons de compatibilité, c'est pour cela que certains hébergeurs conservent ce paramètres activé. Cela "te fais une belle jambe" sûrement mais c'est pour t'expliquer pour quelles raisons les hébergeurs conservent ce paramètre. Bien que beaucoup d'entre eux n'ont fait cela que pour éviter les questions que tu poses, certains on pris sur eux et on décidé de désactiver ce paramètre par défaut pour assurer une meilleure sécurité à leurs serveurs mutualisés... Lien vers le commentaire Partager sur d’autres sites More sharing options...
ste Posté 26 Août 2005 Partager Posté 26 Août 2005 Comme le dit TheRec, sécuriser ses variables, et donc les définir, et vérifier absolument la concordance retournée est impérative ! Une fonction "sécurisée" de test, telle que la suivante, est certainement très intéressante de ce point de vue, surtout en termes de valeurs qui peuvent être injectées dans des variables pour base de données ou accessibles à l'utilisateur : <?php# On n'exécute la boucle que si nécessaireif(get_magic_quotes_gpc() == 1) {# Définition de la fonction récursive. function remove_magic_quotes($array) { foreach($array as $key => $val) { # Si c'est un array, recurssion de la fonction, sinon suppression des slashes if(is_array($val)) { remove_magic_quotes($array[$key]); } elseif(is_string($val)) { $array[$key] = stripslashes($val); } } unSet($key, $val); }# Appel de la fonction pour chaque variables.# Notes, vous pouvez enlevez celle d'on vous ne vous servez pas.# Personnellement, j'enlève $_REQUEST et $_FILES remove_magic_quotes($_POST); remove_magic_quotes($_GET); remove_magic_quotes($_REQUEST); remove_magic_quotes($_SERVER); remove_magic_quotes($_FILES); remove_magic_quotes($_COOKIE);}?> Ainsi, si la constante 'magic_quotes_gpc' est défini - le test par la function PHP 'get***' s'en assure - et dès qu'elle trouve une chaine de caractères, elle l'a passe à la moulinette de la function PHP stripslashes ! Autrement, il n'y en a pas besoin... Lien vers le commentaire Partager sur d’autres sites More sharing options...
oxyd-x Posté 26 Août 2005 Auteur Partager Posté 26 Août 2005 Salut, merci à vous pour vos réponses, concernant le typage des données, je le fais déjà, le hic, c'est que j'ai TOUJOURS programmé avec un globals sur off. Je suis donc perdu maintenant que cette option est obligatoirement active. Merci à vous pour votre aide, @+ sur le hub Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant