register_globals off ou off et faux-on, problème or not problème Options

[corbin]

Bonjour,

suite à une petite réactivation de l'Oscien qui dort en moi et quelques télescopages imaginés entre la nouvelle version r_g off et applications r_g on, j'ai :

- constaté qu'il y relativement peu de posts récents sur le sujet à part celui sur la dernière version :
ça marche aussi bien si on ne se préoccupe de rien ? (je vous rassure, je n'y crois pas)
les anciennes versions en production ne sont pas actualisées ?
tout le monde programme tellement bien que ce n'est pas un problème de réécrire ce qu'il faut réécrire ?
y'a un truc ... ?

- noté l'emplacement 1 et 2 des deux contributions qui font d'un r_g off, un r_g on (j'ai laissé de côté les modifs de htaccess et de php.ini)

- enfin trouvé cette solution ici:

Simplifier le code

L’idée est finalement simple : au lieu d’énumérer les variables potentiellement récupérables, partons plutôt du tableau qui les contient, soit par exemple le tableau _GET.

Il suffit, pour toutes les clés X définies dans le tableau _GET à l’appel du script, c’est-à-dire tous les noms des variables qui ont été passées par la méthode GET, de générer la ligne de code $X = $_GET[’X’].

Bien... Maintenant, il faut l’écrire en PHP...

Eh bien en fait c’est facile. Voici le fichier Recup__GET_vars.php à inclure [1] (au début de vos scripts PHP écrits pour register_globals = On afin qu’ils fonctionnent immédiatement en register_globals = Off du point de vue des variables GET. [2]

Code

<?php while (list($key, $val) = each($_GET)) {$$key=$val;} ?>

Court, non ?!!

Explications

Pour commencer on va récupérer les paires (clé, valeur) du tableau _GET, c’est-à-dire les paires ("nom de variable", $_GET[’nom_de_variable’]). La fonction each($_GET) va beaucoup nous aider. Extrait de la doc PHP :

each($array) retourne la paire clé/valeur courante du tableau array et avance le pointeur de tableau. Cette paire est retournée dans un tableau de 4 éléments, avec les clés 0, 1, key, et value. Les éléments 0 et key contiennent le nom de la clé et 1 et value contiennent la valeur.

D’après cette définition, list($key, $val) = each($_GET) met dans $key l’élément de clé "0" du tableau renvoyé par each, c’est-à-dire le le nom de la variable. De la même manière $val est instanciée par l’élément de clé "1" du tableau renvoyé par each, donc la valeur de la variable ayant pour nom $key.

Reste le problème de désigner la variable elle-même (soit $V) dans notre code alors que nous ne disposons que d’une variable ($key) de type chaine contenant le nom de cette variable (soit "V"). L’idéal serait de pouvoir écrire $$key et que PHP l’interprète comme $V...

Ça tombe bien, PHP permet ça : c’est fini.

[1] La commande require(Recup__GET_vars.php) inclura et exécutera le code de Recup__GET_vars.php. Toutes les variables définies dans Recup__GET_vars.php seront disponibles pour le script incluant. L’absence du fichier en argument de require produit une erreur fatale, tandis qu’on a seulement un warning avec la fonction voisine include.

[2] Il suffit bien sûr de remplacer GET par un autre registre (POST, etc.) pour créer le fichier monoligne à inclure permettant de gérer les variables de ce registre.

par G a.k.a Gérard Milhaud

[maxime]

Quelques commentaires :

Register_global est sur off pour des raisons de sécurité. Pas facile à exploiter, mais cela peut exister.
La solution citée va provoquer les mêmes problèmes de sécurité (pas flagrant mais bon, pas très "bonnes pratiques du codeur").
Autant mettre un register global sur off via htacess dans ce cas, c'est plus simple.
Si ce n'est pas possible, la solution postée peut faire l'affaire, mais il faut penser à toutes les variables, notamment _POST et _SESSION.

[shoprun]

Pour ma part je reste assez partagé sur ce genre de solutions. (comme Maxime).

Cela fait surement ce qui est attendu, c'est à dire de faire tourner osC quelque soit la valeur de la directive register_global, mais au bout ça reste du faut register_global Off s'il est à Off.

Je dirais même pire, car un register_global à On, on le dit partout, et depuis longtemps, n'est pas très sécurisé car il est permis d'exploiter une variable renvoyée par $_GET ou $_POST directement par son nom (genre $ma_var), donc sans passer par les tableaux super globaux.
Donc mettre ce type de code alors que sa directive est à Off (imposé/évolué par son hébergeur), ça revient à un register_global à On, donc de prendre ou de conserver les mêmes risques.

Faux savoir tout de même que ce genre de codes ne tiennent pas du tout compte des types de données qui sont renvoyées, car c'est tout simplement impossible de le savoir à l'avance, du coup, tout est permis, du moins presque, on peu y mettre des routines de code anti-hack, mais seront ils sûr !!!.
A l'inverse, si on s'occupe de récupérer via $_GET ou $_POST, on peut traiter/typer chaque variable de manière individuelle, et là les risques diminues fortement, car un simple typage comme (int)$_POST c'est très radical (par exemple).

Sérieux, je préfère de loin constater un plantage de mon osC me disant que telle ou telle variable est inconnue, donc de me forcer à corriger mon code pour récupérer celle ci via $_GET ou $_POST.

Ceci dit, tu soulève un point où même dans les versions les plus récentes, c'est le même types de code qu'il y a pour les variables de sessions, car on y accède directement par leur nom (genre $customer_id).
D'ailleurs, et sauf erreur, si on jette un oeil dans la MS3, ce n'est plus le cas, les sessions sont exploiter via $_SESSION.
Ca a donc évolué. On peu se poser la question : Pourquoi ?


La dessus, effectivement, pas beaucoup en parlent, sinon jamais.
Je ne peux pas te dire ce que font ceux qui ont des anciennes boutiques.
Appliquent ils ces correctifs (r_g On/Off) ?
Repartent ils sur des versions plus récentes ?

[corbin]

Je ne peux pas te dire ce que font ceux qui ont des anciennes boutiques.

moi, je peux : et non des moindres

A savoir que ces versions (US et Française) sont des RC donc pas définitives, puisqu'une RC2a US est sorti et que cette version est en cours de réalisation ici.
Donc modifier en profondeur une boutique en prod avec tous les risques que cela comporte avec une RC me parait peut être un peu précipité.
Personnellement, mes boutiques vont rester telle qu'elles sont. Les changements pour les register_globals ne m'est pas utile par exemple car ca, ca va changer le comportement de la boutique et des contribs installées antérieurement, vont certainement ne plus fonctionner correctement.

Si c'est pour remonter de la boutique neuve, pas de problème mais attendez-vous à des mises à jours successives (RC2a FR puis RC3 US et RC3 FR s'il y a lieu)

les lecteurs attentifs auront senti l'air iodé.
De là à dire que les r_g sur on, on s'en f... parce que le problème de sécurité, qui existe, est statistiquement insignifiant , est-ce pousser le bouchon* trop loin !?
* c'est de circonstance pour ma référence

[shoprun]

Donc modifier en profondeur une boutique en prod avec tous les risques que cela comporte avec une RC me parait peut être un peu précipité.

Je reste un peu dubitatif la dessus
Pour le "précipité", la dessus tout à fait d'accord, il y a pas lieu de se précipité.
"il y a pas le feu au lac" comme dirait l'autre
On peu envisager de faire les modifs dans la plus grande tranquillité, à la fois chez soi et dans un répertoire (avec une restriction) sur son hébergeur, et on peu très bien se donner 6 mois, 1an, voir plus pour le faire, mais il faut le faire.

Par contre, pour ce qui est du "modifier en profondeur", là faut pas pousser, car franchement, c'est très loin d'être insurmontable.
Le problème, on le connait, c'est juste des codes qui utilisent directement une variable alors que celle ci est renvoyée par $_GET ou $_POST. Suffit donc de l'initialisée correctement au début, et tout le reste suit dans la page.
Que ça soit long car on a installé une 100ène de contributions (sinon plus), là, d'accord.
Aussi, j'ai plutôt tendance à croire que pour les contributions les plus utilisées, les correctifs sont appliqués, ou le seront petits à petits.
Mais encore, il y a la communauté, ici même, et si on coince sur une contribution, ou encore qu'on est hésitant sur le "comment faire", et bien si on explique le problème, il y a de forte chance d'avoir une aide.

Le problème que je remarque souvent dans ce genre d'évolution, c'est que beaucoup attendent la dernière minute, c'est à dire au moment ou son hébergeur impose l'évolution.
J'ai vraiment remarqué ça dans le passage Ph4->Php5 et MySQL4->MySQL5.
Pourtant, et pour peu que l'on prenne le temps de s'informer, les informations sont données bien avant, les soft annonces clairement leurs évolutions.
Ici, pour le cas du register_global, cette directive n'est plus présente dans Php6, mais c'est pas demain la veille que les hébergeur imposeront Php6, mais tu peux être sûr qu'il y aura des boutiques qui vont attendre la dernière minute pour ce dire "comment rendre compatible ma boutique Php5 vers Php6".
Ou encore, je ne serais pas étonné qu'il y aura encore des boutiques (ou autre d'ailleurs) en pure Php4.
D'ailleurs, osCommerce bien qu'il soit compatible Php5, ça reste purement et simplement du Php4.


Le fond du problème est là, c'est que beaucoup attendent le dernier moment pour faire évoluer sa boutique, son projet je dirais même, alors qu'on dispose de plusieurs années pour le faire, 2 ou 3 ans facile, sinon plus.
Pourtant, les soft eux évoluent en permanence, que ce soit Linux, Apache, MySQL, Php etc, etc ...

[maxime]

Si cela vous intéresse, voici comment un peu de méthodologie, quand j'ai migré le code (dans les grandes lignes).
La caractéristique du passage a register_global sur off est grosso-modo que cela ne plante pas. Donc pas d'erreur, à part des notice qui alertent (d'où l'étape 1).

1) Je loggue toutes les erreurs, et y compris les Notice et les corrige. C'est assez pénible, car les notice il y en a !!!
2) Je remplace automatique tous les $HTTP_* par $_* Rien à voir avec register_global, mais si on se pose la question de register_global, autant se la poser pour register_long_array, d'autant que c'est simple à corriger.
3) Je passe en revue les problèmes évidents dans le code et quelques tests
4) Je fais une sorte de béta publique en loggant les erreurs (et les notice).
5) Je corrige les notice

A priori ça marche

Ce message a été modifié par maxime - 11 Dec 2008, 08:46.

[corbin]

Si cela vous intéresse, voici comment un peu de méthodologie, quand j'ai migré le code (dans les grandes lignes).
La caractéristique du passage a register_global sur off est grosso-modo que cela ne plante pas. Donc pas d'erreur, à part des notice qui alertent (d'où l'étape 1).

1) Je loggue toutes les erreurs, et y compris les Notice et les corrige. C'est assez pénible, car les notice il y en a !!!
2) Je remplace automatique tous les $HTTP_* par $_* Rien à voir avec register_global, mais si on se pose la question de register_global, autant se la poser pour register_long_array, d'autant que c'est simple à corriger.
3) Je passe en revue les problèmes évidents dans le code et quelques tests
4) Je fais une sorte de béta publique en loggant les erreurs (et les notice).
5) Je corrige les notice

A priori ça marche

Je pense que c'est effectivement très intéressant et je te proposerai même que tu reprennes ton texte pour en faire un nouveau post ici-même (et ce, sans Tardi, humour bande dessinée) "Méthodologie de correction et de mise à jour des versions OsC";
je n'ai rien trouvé de tel dans la FAQ ... mais en quelques mois j'ai perdu pas mal de repères !
Comprenons-nous, je ne veux pas te mettre au boulot pour développer ce thème, mais ton texte, saupoudré des remarques de shoprun, me semblent judicieux et, un peu détaillé, le sujet me parait digne d'épinglage (et bientôt alimenté par oneill qui déclarait mettre en ligne la liste des modifications effectuées dans un avenir proche*).
(* vous voyez, je me suis fait larguer, mais je travaille pour remonter la pente )
D'autant que ces diverses modifications m'ennuient quant à la validité de la liste des contributions : pour savoir qu'on ne va pas s'enquiquiner avec une installation, il faudrait un nouveau critère "version xxx approved" ... pffffff

Ce message a été modifié par corbin - 11 Dec 2008, 10:12.

[delete]

car un simple typage comme (int)$_POST c'est très radical (par exemple).

Je rejoint shoprun là-dessus. Un Transtypage ou un Filtrage est indispensable sur toutes les valeurs 'externes' au script exécuté (Donc GET POST MySQL & Fichiers).

[maxime]

Je pense que c'est effectivement très intéressant et je te proposerai même que tu reprennes ton texte pour en faire un nouveau post ici-même (et ce, sans Tardi, humour bande dessinée) "Méthodologie de correction et de mise à jour des versions OsC";
je n'ai rien trouvé de tel dans la FAQ ... mais en quelques mois j'ai perdu pas mal de repères !

Voilà Corbin, j'essaierais de prendre un peu de temps pour développer et tenir compte de la relecture de tous.
http://www.oscommerce-fr.info/forum/index....showtopic=59063

[delete]

Topic à retenir...

Dans la lignée de ce post, il est aussi intéressant de souligner le problème de CHARSET d'osC.

Il conviendrait également qu'à l'avenir les classes/fonctions osC soient prévu avec un encodage UTF-8 ou 16 plutôt que ISO-8859-1.

Donc +1 pour Register Global et remarque pour le CHARSET ...

Sans polluer le post de maxime il est effectivement à proscrire :

Code

<?php while (list($key, $val) = each($_GET)) {$$key=$val;} ?>

Côté performances, je ne suis pas du même avis, les requêtes SQL sont largement plus lourdes et importantes à considérer que le code PHP... optimisez de préférence les requêtes plutôt que le code ... (sujet de débat... je sais mais j'ai des arguments !)

[corbin]

Voilà Corbin, j'essaierais de prendre un peu de temps pour développer et tenir compte de la relecture de tous.
http://www.oscommerce-fr.info/forum/index....showtopic=59063

je le mets ici pour ne pas polluer ton nouveau post : super et merci de la part de tous !