FONCTION DE SÉCURITÉ CONTRE LA POLLUTION DES VARIABLES ET LE HIJACKING
coucou747
Messages postés
12303
Date d'inscription
mardi 10 février 2004
Statut
Membre
Dernière intervention
30 juillet 2012
-
6 déc. 2005 à 18:03
FoxLeRenard Messages postés 47 Date d'inscription samedi 2 juillet 2005 Statut Membre Dernière intervention 10 avril 2024 - 6 mai 2009 à 09:44
FoxLeRenard Messages postés 47 Date d'inscription samedi 2 juillet 2005 Statut Membre Dernière intervention 10 avril 2024 - 6 mai 2009 à 09:44
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/34938-fonction-de-securite-contre-la-pollution-des-variables-et-le-hijacking
https://codes-sources.commentcamarche.net/source/34938-fonction-de-securite-contre-la-pollution-des-variables-et-le-hijacking
6 mai 2009 à 09:44
Oui Oui bien sur je comprends la vitesse d'évolution ...
mais il reste encore bien des serveurs mal protégés !!!
A bientôt le plaisir de te croiser
6 mai 2009 à 09:36
Mais avant d'utiliser ce code vérifie ta version de php et surtout que register_globals est activé sinon ça ne sert à rien de l'utiliser... ça fait 4 ans que j'ai posté cette source php a évolué depuis... .. . ;o)
@ tchaoo°
6 mai 2009 à 08:45
Au passage merci de m'avoir répondu si vite t' es génial !
6 mai 2009 à 08:11
@ tchaOo°
6 mai 2009 à 06:26
avec google on peut atteindre nos sites par nimporte quel PHP alors comment utiliser cette fonction juste a l'arrivée d'un visiteur,
En fait j'irais même bien plus loin, si j'ais passé cette bariére, j'ouvre
un autre onglet sur la même page je serais vu dans la même session non ?
9 oct. 2006 à 14:29
14 janv. 2006 à 02:52
if(isset($_REQUEST['GLOBALS']) || isset($_FILE['GLOBALS'])){
die('Warning Global overwrite attempt');
}
comme quoi... .. . ;o)
@ tchaOo°
26 déc. 2005 à 10:29
Sait on jamais, on tombe sur tout et n'importe quoi, ca peut toujours aider dans ce cas la !
24 déc. 2005 à 04:01
Qui plus est un whois de l'ip pointe vers les states donc c'est surement pas moi qui es fais ça par erreur... ça confirme juste l'utilité de ce petit bout de code... .. . ;o)
@ tchaOo°
23 déc. 2005 à 21:16
Variable attempt : not alowed variable $GLOBALS by Visitor (64.60.106.154)
Variable attempt : not alowed variable $_REQUEST by Visitor (64.60.106.154)
Ce ne sont pas le genre de truc marrant à lire...
PS : J'ai oublié les '_' dans le petit script, que revoici !
<?php
if( ini_get(register_globals) ) {
foreach ($_REQUEST as $request_key => $request_value) {
if( preg_match('@^[\w_]{1}[\w\d_]*$@', $request_key)
and isset($$request_key) ) {
unset($$request_key);");
}
}
}
?>
23 déc. 2005 à 17:35
Pourquoi dis tu...
"Donc, je ne suis pas étonné que tu te fasse virer à l'execution."
???
@ tchaOo°
23 déc. 2005 à 15:01
<?php
// Effectively turn off dangerous register_globals without having to edit php.ini
if (ini_get(register_globals)) // If register_globals is enabled
{ // Unset $_REQUEST keys
foreach ($_REQUEST as $request_key => $request_value) {
if (preg_match('@^\w{1}[\w\d]*$@', $request_key) and isset($$request_key) ) {
unset($$request_key);");
}
}
}
?>
23 déc. 2005 à 14:58
Le code tout moche avec les ereg et patati... effectivement, il est tout moche et bien débile !!! Je l'ai copié coller depuis le site fr.php.net (la fameuse Sainte Ecriture).
Le c** qui à écrit ça efface les variables get, puis post et enfin request !?! Euh.. non ! request reprend les post et les get....
Donc, je ne suis pas étonné que tu te fasse virer à l'execution.
En voici une version un peu mieux :
(preg et plus efficace que ereg)
(eval est inutile dans ce cas puisqu'il existe les variables-de-variables)
<?php
// Effectively turn off dangerous register_globals without having to edit php.ini
if (ini_get(register_globals)) // If register_globals is enabled
{ // Unset $_REQUEST keys
foreach ($_REQUEST as $request_key => $request_value) {
if (preg_match('@^\w{1}[\w\d]*$@', $request_key {
unset($$request_key);");
}
}
}
?>
On apprchoe de quelque chose de pas mal là !
Non ?
Biz et Noyeux Joël à tous
23 déc. 2005 à 00:23
"QUE TU LE VEUILLE OU NON? QUE TU TROUVE CA DINGUE OU PAS IL Y A ENCORE DES HEBERGEURS QUI ONT REGISTER GLOBAL A ON !!! ET PAS QU'UN PEU... .. ."
@ tchaOo°
22 déc. 2005 à 23:28
C'est pas la peine d'en faire un plat non plus, mais je penses qu'essayer de s'accrocher à son register global, essayer de sécuriser cette option pour à tout prix la conserver au lieu de la mettre à off, est un vice.
Citation : la bible (www.php.net)
Lorsqu'elle est activée, register_globals va injecter (empoisonner) vos scripts avec toutes sortes de variables, comme les variables issues des formulaires HTML. Ceci, couplé au fait que PHP ne requiert pas d'initialisation de variable signifie que la programmation de script peu sûr est possible. Ce fut une décision difficile de la communauté PHP, mais finalement, il a été décidé de désactiver par défaut cette variable. Lorsqu'elle est active, le programmeur ne sait pas exactement d'où provient le contenu de la variable, et ne peut que faire des suppositions.
22 déc. 2005 à 18:36
Tiens c'est marant j'ais eu une drole d'entrée dans le logs de sécu d'un des sites qui utilise cette fonction...
Variable attempt : not alowed variable $GLOBALS by Visitor (64.60.106.154)
Variable attempt : not alowed variable $_REQUEST by Visitor (64.60.106.154)
On m'aurait menti... maintenant faudrait que je developpe l'écriture du log pour avoir plus d'infos (requete exacte)... .. .
@ tchaOo°
21 déc. 2005 à 21:46
Après, moi je dis rien... Mais je pourrais dire autre chose : ini_set(register_globals,'0');
(en haut de chaque script)
<?php
// Effectively turn off dangerous register_globals without having to edit php.ini
if (ini_get(register_globals)) // If register_globals is enabled
{ // Unset $_GET keys
foreach ($_GET as $get_key => $get_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $get_key)) {
eval("unset(\${$get_key});");
}
} // Unset $_POST keys
foreach ($_POST as $post_key => $post_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $post_key)) {
eval("unset(\${$post_key});");
}
} // Unset $_REQUEST keys
foreach ($_REQUEST as $request_key => $request_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $request_key)) {
eval("unset(\${$request_key});");
}
}
}
?>
21 déc. 2005 à 21:27
"Je voulais dire qu'il fallait vraiment être fou pour coder avec un register globan à ON. D'où l'inutilité de ce genre de source."
Il serait bien que tu relise un peu les commentaires de cette source... que le fait de coder avec register_global tienne de la folie est un fait mais il n'en reste pas moins que certains le font quand même donc c'est bien de traiter ces gens là de fou mais proposer des moyens de rendre les scripts en cause moins passoire c'est mieu ne crois tu pas... qui plus est et là je commence vraiment à avoir la sensation de me répéter je vais donc le dire haut et fort (lOol)... .. .
QUE TU LE VEUILLE OU NON? QUE TU TROUVE CA DINGUE OU PAS IL Y A ENCORE DES HEBERGEURS QUI ONT REGISTER GLOBAL A ON !!! ET PAS QU'UN PEU... .. .
Voila donc avoir un avis sur la chose c'est bien mais ça ne change pas grand chose sur les fait... moi je trouve totalement con que l'on puisse s'entre tuer pour des raisons ethnique ou religieuse et pourtant ça n'empeche pas qu'il y a des guerres de par le monde... tu me suis the_template... .. .
Voili voilou... .. .
@ tchaOo°
21 déc. 2005 à 19:56
Reste cool the_template, je pense (j'espère) que tout le monde avait compris l'ironie de ton premier message (ou ben alors y'a pis des boeufs ! J'vous l'jure, c'est-y pas croyable...).
Alors ne change rien & A+
20 déc. 2005 à 12:58
^_^
20 déc. 2005 à 12:31
Je saisis plus là. C'est drôle quand même que deux types me tombent gentillement dessus parce que j'ai marqué "oO lol", destiné à montrer tout mon étonement à voir que des gens n'ont pas encore compris qu'il fallait mettre register global à off.
Bon ok je mettrais plus "oO lol".
lol.
20 déc. 2005 à 11:39
20 déc. 2005 à 11:06
Je voulais dire qu'il fallait vraiment être fou pour coder avec un register globan à ON. D'où l'inutilité de ce genre de source. Outre la sécurité qui est complétement miuse de côté, un register global à ON pourrit vraiment le code, on ne s'y retrouve plus entre les variables qui sont fournies par l'utilisateur et les autres.
Ce n'est pas pour rien que php a décidé de mettre les register global à off par défaut.
J'espère que mes post seront mieux compris la prochaine foi (lol, il était pas très clair non plus)
@+
19 déc. 2005 à 20:32
@ tchaOo°
19 déc. 2005 à 20:05
19 déc. 2005 à 19:53
13 déc. 2005 à 10:11
Effectivement Sourceforge propose plus de sources abouties qu'ici mais la différence s'arrête là... l'interet d'un site comme phpcs est, à mon avis, le caractère éducatif de son contenu... alors cela peut être rasoir pour les pro, habitués et autres amateurs éclairés du php de voir autant de bout de code non fini ou baclés (bien qu'il y ai un paquet de très bonne sources sur le site) mais il ne faut pas sous estimer l'impact d'un tel site... phpcs regorge de bonne idées et de trucs qui ne sont pas forcement accessible via des site plus ""pro""... et c'est, encore à mon avis, ce qui fait à la fois sa force et son point faible... .. .
On aprend d'autant plus dans un environement abordable bien que des erreurs puissent se glisser de ci de là alors que, généralement, on avance plus lentement au milieux de ""pro"" bien que cela se fasse plus proprement c'est un fait... ça ne s'applique pas qu'à l'informatique ou au codage mais le net fragmente pas mal la transmition du savoir par niveau rendant ce déroulement éducatif d'autant plus vrai... tout du moins c'est le constat que j'en ai fait à force... .. .
En attendant moi... en tant qu'amateur semi éclairé... qui pige pas grand chose à la langue de shakespear... j'aime bien... .. . ;o)
@ J_G... qu'entend tu par équilibré ma source... elle penchait... lOol... .. ?
^_^
@ tchaOo°
13 déc. 2005 à 10:02
Ouyais, SourceForge, c'est vrai, mais ce n'est pas à proprement parlé un repository de sources; pour moi, c'est un repository de projets.
Puisque t'es ingé, tu sais qu'il est très différent de bosser sur...le code d'une classe bdd, que de bosser sur un applicatif web dédié à la gestion complète d'un réseau de transport (par exemple). Dans le premier cas, on bosse sur une source, éventuellement un petit ensemble de classes, et la démarche ne sera pas tout à fait la même que dans le second cas, où on bosse sur ujn vrai projet, avec de multiples imbrications, orienté vers un domaine d'application plus ou moins précis. Ca ne se gère pas de la même manière. SourceForge présente plutôt de vrais bon gros projets bien lourds :-)
Je ne savais pas qu'il y avait validation sur php.net tien. Mais ça ne m'étonne guère :-) Je n'ai jamais contribué là-dessus; tout au plus à la liste de distribution dév php, de temps à autres.
13 déc. 2005 à 09:43
<<
D'ailleurs, aucun site à ma connaissance n'a que des sources de très grandes qualités (genre, que des phpmyadmin, par exemple).
>>
=> sourceforge.net (?) C'est de là-bas que sort phpMyAdmin.
<<
sur php.net il y a pas mal de "gourous"
>>
C'est à dire qu'avant d'être affiché, un post doit être validé par les administrateurs du site (qui ne doivent pas être très-très loin des concepteurs de PHP). Seuls ceux ajoutant qqes choses de réél resteront. Ce n'est pas tout à fait la même politique que sur PHPCS.
kankrelune, j'ai équilibré ta source...
13 déc. 2005 à 09:29
Après, des sources vraiment utiles, y en a, mais moins. Le problème c'est que CS est TRES visité, et il est difficile de le cantonner à un site de sources vraiment pro. D'ailleurs, aucun site à ma connaissance n'a que des sources de très grandes qualités (genre, que des phpmyadmin, par exemple).
Quant aux sources php.net, enfin plutôt les petits scripts, ils sont souvent très bons, mais il ne faut pas se leurrer : sur php.net il y a pas mal de "gourous"...la moyenne d'âge n'est pas la même, les compétences non plus. Bref, ce n'est pas la même cible, ni le même domaine d'application.
13 déc. 2005 à 02:33
Sinon voila je pense que cette source peut autant être pédagogique qu'utile... nombreux sont les hébergeurs qui tournent encore avec register global à on... après faut pas non plus se croire à l'abri de tout en mettant cette fonction... on ne le répètera jamais assez... .. . ;o)
Je sais pas qui à mis 10 mais c'est trop... n'exagérons rien... mais c'est gentil quand même... .. .
^_^
@ tchaOo°
ps : je prend en compte ton idée J_G et modifis la source en concéquence... .. .
12 déc. 2005 à 20:53
Mais je parle des sources postées par les utilisateurs et non celles qui illustrent les fonctions...
12 déc. 2005 à 20:38
12 déc. 2005 à 20:10
De même, on est d'accord sur ce point : l'informatique est avant tout une question "de passion, de vocation, ou du gout des choses qui marchent".
Mais je ne sais pas si tu regardes les scripts postés sur php.net, il sont rarement plus compliqués que ceux postés ici.
En voici un qui correspond à cette source :
------------------------
If you're on a shared environment, and have no way of disabling register_globals, this little "unregister_globals" snippet could come in handy:
<?php
if (@ini_get('register_globals'))
foreach ($_REQUEST as $key => $value)
unset($GLOBALS[$key]);
?>
------------------------------------
Bon, pas de quoi s'en relever la nuit non plus...
Alors je ne dénigre pas les sources postées ici. Je suis informaticien (de profession et de gout des choses qui marchent, mais pas de vocation ni de passion), ingénieur, ... Et même si je n'utilise plus les sources de PHPCS depuis de belles lurettes, je trouve que beaucoup ont leur mot à dire dans la "communauté" PHP.
Et, toujours à mon gout, beaucoup d'informaticiens en herbe font leurs débuts sur ce site. Véritable tremplin vers une connaissance accrue de PHP.
Après, c'est vrai, tout n'est pas rose! Combien de fois la même question ? Combien ne comprennent pas que PHP est coté serveur et ne vois pas pourquoi c'est ainsi... Beaucoup de posts émanent de gens qui n'ont aucune culture de l'outil informatique (et souhaitent juste se faire une page perso pour mettre des photo en ligne : "Pourquoi ça revient pas à la ligne ?"). Mais justement, ils s'y intéressent. Alors autan leur donner des cefs pour mieux comprendre.
Bon, je délire un peu là... Mais tu m'excuseras. Hein ?
12 déc. 2005 à 19:28
c'est une question de passion, de vocation, ou du gout des choses qui marchent... pas une question de proffession...
12 déc. 2005 à 12:32
Bon effectivement, ce script est destiné à ceux et celles qui ont register global à On, qui ne vérifient pas la provenance de leur variables et qui en plus ne les initialises pas...
Bref, ce script est destiné au non-informaticien ;)
Donc il a le mérite de leur montrer qu'un script PHP peut-être "piraté".
Par contre, au lieu de rediriger vers la page d'index... ou même de tester l'existance de ces variables... Moi je les initialiserais de force.
# foreach ($vars_array as $bad_global)
# $_REQUEST[$bad_global] = NULL;
Comme ça, le pirate ne sais même pas si il est en train de toucher un point sensible. Et la navigation du site ne sera pas affectée par la fonction.
A+
8 déc. 2005 à 13:55
@ FhX => oui sauf que tous les hébergeurs n'ont pas register global à off... malheureusement... loin de là... .. .
@ Malalam => bien entendu qu'il vaut mieux prendre dès le début les bonnes habitudes de codage... c'est d'ailleurs ce que je dis dans la présentation il me semble... cependant ce n'est pas le cas de tout le monde et quand register global est à on on peut ouvrir des failles grosses comme des maisons avec pas grand chose... .. .
Ce code à déja fait ses preuves contre des attaques par pollution des variables et surtout contre des tentatives de hijacking... après biensur le top c'est register global à off mais dans le cas d'un CMS comme xoops il faut prévoir tous les cas de figure... et pour ceux qui sont hébergés avec register global à on je pense que ce code ne sera pas inutile (et c'est pas pour les ressources qu'il prend lOol)... .. . ;o)
@ tchaOo°
7 déc. 2005 à 14:50
La vertu pédagogique, c'est la moralité à appliquer à ce code (celle de =Fhx) :
Moralité :
"register_globals = 'Off'
Et on en parle plus :o"
Parce que je préfère que les débutants prennent cette habitude, plutôt que celle d'utiliser un tel code.
Maintenant, ça peut servir...dans le cas où l'on héberge un site chez un hébergeur vraiment très très pourri ;-)
Il n'empêche, on récupère ses $_GET toujours, et jamais dans le cadre d'un "extract" permanent, c'est la bonne méthode. ON teste l'existence des variables reçues avec isset, empty, is_numeric etc...tout ce qu'il faut pour la cadrer un maximum; on teste sa provenance avec $_GET, $_POST, $_COOKIE, $_SESSION etc... (et pas $_REQUEST...), on l'escape, on lui fait subir maints traitements afin de la sécuriser au maximum avant de daigner la réinjecter dans la suite du traitement!
Voilà la bonne façon de procéder.
Et ce code montre pourquoi.
7 déc. 2005 à 13:04
register_globals = 'Off'
Et on en parle plus :o
7 déc. 2005 à 09:25
Je verrais bien qu'on lise les fichiers PHP exécutés pour établir la liste des variables qui y sont déclarées et en interdire le passage par une autre voie... mais le plus simple c'est quand même de mettre les auto globals à off, c'est pour ça que ça a été imaginé, parce que ça crée trop de problèmes :/
6 déc. 2005 à 18:12
La boucle vérifie que des variables sensibles ne sont pas passées par $_GET pour tenter de les poluer ou de les détourner... .. .
imaginons que tu utilise une variable $monSiteConfig résultant d'une requete sql par exemple si la boucle trouve $_REQUEST['monSiteConfig'] c'est que l'on essaye de s'attaquer à cette variable via l'url... c'est aussi simple que ça... .. .
Après effectivement mettre $_GET dans la recherche est pas très utile... je n'y avais pas pensé... je ferais suivre... .. .
^_^
@ tchaOo°
6 déc. 2005 à 18:03
et pourtant, t'as _GET dedans...