J'y comprend rien !!!!

WebRod wrote:

[grande conversation à laquelle j'apporte mon grain de sable]

Si la BS le fait, pas besoin de le faire.
Si le flag est à OFF, pas besoin d'en rajouter non plus....

Oui ok, bien...

La seule chose que tu oublies c'est qu'on (en tant que créateur du
script) ne sommes pas toujours en contrôle (d'ailleur c'est aucunement
notre devoir) l'état de tel ou tel flag...

Rod

S.

Sebastian 'CrashandDie' Lauwers a écrit:

WebRod wrote:

[grande conversation à laquelle j'apporte mon grain de sable]

Si la BS le fait, pas besoin de le faire.
Si le flag est à OFF, pas besoin d'en rajouter non plus....

Oui ok, bien...

La seule chose que tu oublies c'est qu'on (en tant que créateur du
script) ne sommes pas toujours en contrôle (d'ailleur c'est aucunement
notre devoir) l'état de tel ou tel flag...

Pas si sûr : tout dépend si tu développes pour "publier" le script, ou
pour un besoin lié à un site donné....

Rod

S.

exact, il est vrai que dans mon cas je ne développe que pour des sociétés
qui ont leur propre serveur et où j'ai la possibilité de faire changer la
config.

C'est vrai que si tu développes un script pour le commercialiser ou pour le
publier au plus grand nombre, mieux vaut sécuriser un max, et la vision des
choses est différente

Rod

Re,

exact, il est vrai que dans mon cas je ne développe que pour des sociétés
qui ont leur propre serveur et où j'ai la possibilité de faire changer la
config.

Même dans ce cadre là, moins tu es dépendant de la config du serveur mieux
ça vaut. Ne serait-ce que parce que la config de la machine de recette
n'est pas nécessairment celle de la production...

Justement, quand à partir de la 4.x.x les nouvelles instalations de php
étaient livrées par défaut avec register_globals=Off, ça a foutu un beau
boxon dans beaucoup de scripts. Dans les miens, ça n'a rien changé parce
que ma fonction de filtrage allait chercher dans $HTTP_ENV_GETVARS (et
POSTVARS tant que $_REQUEST n'existait pas) et je n'ai pas changé une
seule ligne de code pour passer de l'un à l'autre. Chez d'autres, ça a été
un joyeux souk.

C'est vrai que si tu développes un script pour le commercialiser ou pour le
publier au plus grand nombre, mieux vaut sécuriser un max, et la vision des
choses est différente

Pas seulement sécuriser : écrire du code portable. Entre autres en termes
de sécurité.

Par ailleurs, ne pas oublier qu'il y a autant, si ce n'est plus,
d'attaques qui sont faites en interne qu'en externe.

a++;
JG

Re,

Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà
l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il
existe, parce que la base de données est PREVUE POUR LE GERER.
Tout à fait, c'est bien pour cela que j'ai choisi cet exemple ;)

On est d'accord qu'il est inutile de faire quelquechose dans la bd si celle
ci est prévue pour le gérer.

Oui nous sommes parfaitement d'accord.

Pourquoi php ne pourrait -il pas gérer une partie de la sécurité?
Le problème que je soulève est bien celui-ci : il pourrait mais il ne

garanti rien.

Autant si tu as le droit de faire un create table, tu auras nécessairment
le droit de coller dessus une contrainte UNIQUE. Tous les SGBDR
connaissent ce type de contraintes. Il en serait différent pour les clef
étrangères, d'ailleurs.

Autant tu ne PEUX PAS garantir que la plateforme php sur laquelle tournent
tes scripts sera bien en register_globals=Off. Tu l'as vu toi même avec
ton hébergeur.

Et si t'elle était le cas, pourquoi rajouter un
niveau de sécurité au niveau
Si tel était le cas, ce serait inutile. Ce n'est pas le cas. Nous sommes

bien d'accord sur les conclusions mais pour parler prolog, les
hypothèses que tu considères comme prédicats sont fausses.

TOUT A FAIT! C'est ce que je voulais dire, le flag à On est une grosse
connerie qui oblige beaucoup trop à sécuriser ses scripts.

Cette affirmation est discutable, mais là n'est pas mon propos. Tout ce
que je souligne c'est qu'il y a beaucoup de plateformes dans la vraie vie
qui sont en register_globals à ON. On y peut rien, c'est un fait. Donc il
faut en tenir compte, donc initialiser ses variables, ou mettre une
protection d'une manière ou d'une autre (comme ta bidouille, qui est une
bonne idée, mais possède l'inconvénient de devoir être faite sur
**chaque** script public, donc on risque d'en oublier, ou alors il
faut le coller en auto_prepend).

initialisant les variables au début de chaque script, mais justement, ce que
je veux dire, c'est que cela n'est plus utile si c'est à OFF

Affirmation à laquelle je n'adhère absolument pas pour du langage typé
mais non initialisateur automatiquement (exemple : C/C++) ni pour un
langage qui initialise soit disant ses variables mais non typé comme PHP.

Tu peux te permettre de ne pas initialiser certaines de tes variables en
java parce que le langage en connait le type, et le compilateur/jvm te
**garanti** qu'il y aura initialisation. En C, ou en PHP, tu ne peux pas
te permettre de ne pas initialiser tes variables à une valeur connue et
déterminée. En C parce que la valeur sera aléatoire (plus précisement : ça
dépend du compilo et de l'OS), et en PHP parce que tu ne veux pas
nécessairement te pêter un E_WARNING toutes les deux lignes (et que je ne
passe pas en production un script qui ne tourne pas en E_ALL).

De toute façon, ce flag à ON etait une aberration.

C'est une affirmation très discutable qui a déjà fait spinner beaucoup
d'électrons. Dès lors que tu veux faire du filtrage intelligent pour
éviter les injections SQL ou les attaques de type XSS stockées, tu dois
tripoter le contenu de tes variables venant du monde extérieur. Donc que
tu ailles les pêcher dans un HTTP_ENV_GETVARS ou directement par leur nom,
aucune différence. Mais si PHP était dôté d'un vrai système de filtrage
(je ne parle pas de cette piètre tentative genre magic_quotes) alors ce
serait complètement idiot d'aller les coller dans une zone mémoire qui est
quand même super-globale (et après on nous fait la morale sur
l'encapsulation et la poo alors que n'importe où on peut tripoter
$_REQUEST['toto'], laissez moi rire) alors qu'on pourrait limiter la
portée de ces variables au script qui les réceptionne.

Quel idée d'aller initialiser des variables!!
Je présume que tu voulais dire "d'aller ajouter des variables externes

dans l'espace de nommage sans intervention du développeur".
Personnellement, je trouve ça très pratique et beaucoup plus propre en
portée des variables, mais rendu inexploitable pour les raisons de sécurité données ci-dessus.

Il y avait un vrai problème avec register_globals=On. La solution n'était
pas de les passer à Off, ça c'étaitla mauvaise réponse à un vrai problème
(et il y a eut des prises de bec à ce sujet au sein du php group assez
intéressantes). La vraie solution, c'etait de remonter le niveau d'erreur
en cas de variable non initialisée, et de mettre en place un vrai système
de filtrage des données.

D'ici là, tout développeur qui n'initialise pas ses variables
correctement s'expose à la faille.
C'est cà, pour le moment c'est indispensable. (à moins d'utiliser le petit

script que je donnais plus haut et qui annule l'initialisation des
variables)
C'est une solution en effet, mais je ne suis pas d'accord avec toi sur ce

qu'il fait : il n'annule pas, il surcharge/réaffecte si la variable
existe, ou il initialise si elle n'existe pas ;-)

a++;
JG

bon je vais arrêter de polémiquer la dessus ;)
Juste répondre à 1 ou 2 trucs

Si tel était le cas, ce serait inutile. Ce n'est pas le cas. Nous sommes
bien d'accord sur les conclusions mais pour parler prolog, les
hypothèses que tu considères comme prédicats sont fausses.
En l'occurence, je dis que SI le flag est à OFF, y à moins de problème de

"sécurité.
Et DONC, le mettre à ON AJOUTE des problèmes de sécurité
Conclusion: le flag à ON offre des problèmes de séucrité.

Je ne dis pas que le flag est à OFF partout!

Tout ce
que je souligne c'est qu'il y a beaucoup de plateformes dans la vraie vie
qui sont en register_globals à ON. On y peut rien, c'est un fait. Donc il
faut en tenir compte, donc initialiser ses variables,

YES

protection d'une manière ou d'une autre (comme ta bidouille, qui est une
bonne idée, mais possède l'inconvénient de devoir être faite sur
**chaque** script public, donc on risque d'en oublier, ou alors il
faut le coller en auto_prepend).
Ben encore uns fois, dans mon cas, TOUS mes scripts, je dis bien TOUS, font

un include de "init.php".
Ce fichier me sert à faire d'autres include de classes et à initialiser des
variables.
Donc j'ai eu juste à ajouter ma bidouille une seule fois dans ce fichier.
Dans une autre conception ce serait différent, mais ce serait à mes yeux une
bien mauvaise conception ;)

PHP, tu ne peux pas
te permettre de ne pas initialiser tes variables à une valeur connue et
déterminée. En C parce que la valeur sera aléatoire (plus précisement : ça
dépend du compilo et de l'OS), et en PHP parce que tu ne veux pas
nécessairement te pêter un E_WARNING toutes les deux lignes (et que je ne
passe pas en production un script qui ne tourne pas en E_ALL).

en l'occurence ce sont plutot des E_NOTICE non? Il est moins problèmatique
de virer les E_NOTICE que les E_WARNING.

De toute façon, ce flag à ON etait une aberration.

C'est une affirmation très discutable qui a déjà fait spinner beaucoup
d'électrons. Dès lors que tu veux faire du filtrage intelligent pour
éviter les injections SQL ou les attaques de type XSS stockées, tu dois
tripoter le contenu de tes variables venant du monde extérieur. Donc que
tu ailles les pêcher dans un HTTP_ENV_GETVARS ou directement par leur nom,
aucune différence.

Ben pour moi il y a une différence justement!
"un HTTP_ENV_GETVARS " c'est bien pour récupérer les variables d'un
formulaire c'est ca?
Dans ce cas, quand tu vas chercher dans HTTP_ENV_GETVARS tu sais que tu veux
des valeurs d'un formulaire.
Quand tu créés une variable $toto pour l'utiliser dans ton script mais que
cela n'a rien à voir avec un formulaire, et que php t'initialise ta variable
avec des données venant d'un formulaire sous pretexte que le nom d'un champs
a le même nom que celui de ta page, je trouve pas ca trés logique!
Je pense qu'il n'a pas à "créé" de variables ou initialiser des variables
existantes.
On parle de codage "propre", moi je parle aussi de language "propre": qu'il
mette les variables d'un formulaire "proprement" dans un tableau réservé et
c'est tout!!
C'est d'ailleurs ce qu'il fait maintenant donc tout va bien (enfin avec le
fameux flag à off et leur volonté de ne plus autoriser le passage à ON)

Quel idée d'aller initialiser des variables!!
Je présume que tu voulais dire "d'aller ajouter des variables externes

dans l'espace de nommage sans intervention du développeur".
Personnellement, je trouve ça très pratique et beaucoup plus propre en
portée des variables, mais rendu inexploitable pour les raisons de
sécurité données ci-dessus.

En l'occurence non, ce qui me pose problème ce n'est pas qu'il créé des
variables SI je ne les utilise pas (bien que la création de ces variables
soit à l'origine du problème), non, c'est bien le fait qu'il "initialise"
des variables que j'utilise mais qui ne sont pas censées correpondre aux
données du formulaire (voir plus haut) qui me posent problème.

La vraie solution, c'etait de remonter le niveau d'erreur
en cas de variable non initialisée

c'est déjà le cas avec les E_NOTICE non?

D'ici là, tout développeur qui n'initialise pas ses variables
correctement s'expose à la faille.
C'est cà, pour le moment c'est indispensable. (à moins d'utiliser le

petit
script que je donnais plus haut et qui annule l'initialisation des
variables)
C'est une solution en effet, mais je ne suis pas d'accord avec toi sur ce

qu'il fait : il n'annule pas, il surcharge/réaffecte si la variable
existe, ou il initialise si elle n'existe pas ;-)
Euh je ne comprends pas?

Attention, il faut evidemment remplacer dans mon script $$val="" par unset
($$val) (comme expliqué dans un autre message)
Et dans ce cas il n'y a ni surcharge ni réaffectation.
Si la variable existe, elle est supprimée (unset).
Si elle n'existe pas?? Et bien le script ne fait rien!!
Si elle n'existe pas, elle n'est pas dans $_request, donc elle n'est pas
prise en compte dans la boucle.
Il y a donc bien annulation de l'effet du flag à ON sur l'objet Request
puisque tout ce qu'il a créé est supprimée (les variables créés ont
disparues).

Rod

John GALLET a dit le 01/02/2005 à 11h21:

Justement, quand à partir de la 4.x.x les nouvelles instalations de php
étaient livrées par défaut avec register_globals=Off, ça a foutu un beau
boxon dans beaucoup de scripts. Dans les miens, ça n'a rien changé parce
que ma fonction de filtrage allait chercher dans $HTTP_ENV_GETVARS (et
POSTVARS tant que $_REQUEST n'existait pas) et je n'ai pas changé une
seule ligne de code pour passer de l'un à l'autre. Chez d'autres, ça a été
un joyeux souk.

Et bien ton code va pas passer le passage à PHP5 avec le php.ini par défaut.

Re,

Et bien ton code va pas passer le passage à PHP5 avec le php.ini par défaut.
1) m'en fous, avant que je télécharge php5 il a se passer de l'eau sous

les ponts
2) pousserais tu la démonstration jusqu'à émettre une raison possible du
"pourquoi" illustrant cette affirmation de type devinatoire (vu que tu ne
connais pas mon code) ?

a++;
JG

John GALLET a dit le 01/02/2005 à 23h28:

1) m'en fous, avant que je télécharge php5 il a se passer de l'eau sous
les ponts

C'est dommage pour toi.

2) pousserais tu la démonstration jusqu'à émettre une raison possible du
"pourquoi" illustrant cette affirmation de type devinatoire (vu que tu ne
connais pas mon code) ?

PHP5 n'active pas par défaut les tableaux du type $HTTP_GET_VARS, mais
uniquement ceux du type $_GET.
D'ailleurs, tu dis utiliser $HTTP_ENV_GETVARS, qui n'existe pas.

Re,

C'est dommage pour toi.

C'est ton avis et tu le partages. Je n'ai aps de temps à investir tant que
les évolutions ne m'apportent rien ni qu'un de mes clients ne démarre pas
un nouveau projet. Le temps est une des denrées les plus chères qui
soient.

PHP5 n'active pas par défaut les tableaux du type $HTTP_GET_VARS, mais
uniquement ceux du type $_GET.

"allait chercher dans $HTTP_ENV_GETVARS (et POSTVARS tant que $_REQUEST
n'existait pas)"

DONC depuis que $_REQUEST existe, j'utilise exclusivement $_REQUEST.
Depuis le temps que je répète qu'on se fout de la méthode de transmission
des données mais que c'est son contenu qui importe... Faut suivre un peu.

D'ailleurs, tu dis utiliser $HTTP_ENV_GETVARS, qui n'existe pas.
En effet, ma vitesse de frappe clavier est inversement proportionnelle au

nombre de fautes de frappe à la ligne.

a++;
JG