Probleme avec les variables

Thibaut Allender nous a dit le 09/04/2004 20:54:

qu'on utilise isset() ou le code "crade", le resultat est le meme :
$login ne vaudra rien
je prefere mettre la poussiere sous le tapis que d'acheter un aspirateur
industriel, ca suffit pour un appartement

Si tu veux faire l'économie d'un isset() à un endroit où il sera inutile
hormis pour éviter la notice, tu fais:

$login = @$_POST['login'];

et je sais que ca va faire huler les geeks, mais chacun a sa facon de coder
si php tolere qu'on ne declare pas les variables ou qu'on utilise des
index inextistants, c'est pas pour rien.

rhaaaaaa...

--
Bobe (Aurélien Maille)
http://webnaute.net

"la vie d'un geek est un combat perpétuel contre l'imperfection"

Thibaut Allender wrote:

... ou qu'on se tape pas mal des notice
je prefere avoir un code "crade" que de le surcharger de isset() inutiles

C'est ton probleme, rappel moi de ne jamais te demander de CV :)
Ce n'est pas pour coder proprement que je dis ca, je m'en fou
completement de la propreté de ce code, tend qu'il marche et qu'il est
sécurisé.

Et justement, l'erreur reporting sur E_ALL evite de se faire bananer


if(lalal){
$ok = TRUE;
}

if($ok){
// afficher les données banquaires de monsieur bidule
}

Et un petit script.php?ok=TRUE et tu te fait avoir. Alors que en
error_reporting E_ALL, tu auras un signalement de cette erreur et tu la
corrigeras.

qu'on utilise isset() ou le code "crade", le resultat est le meme :
$login ne vaudra rien
je prefere mettre la poussiere sous le tapis que d'acheter un aspirateur
industriel, ca suffit pour un appartement

On voie que tu n'est pas hasmatique.

et je sais que ca va faire huler les geeks, mais chacun a sa facon de coder
si php tolere qu'on ne declare pas les variables ou qu'on utilise des
index inextistants, c'est pas pour rien.

C'est à cause de comportements comme cela que le php à une reputation de
language de newbie plein de failles, merci.

--
Guillaume.

Le 09 avr. 2004, Stephane Santon s'est levé(e) et s'est dit "tiens, si
j'écrivais aux mecs de fr.comp.lang.php"

Peut-être parce que ta constante n'a pas été définie, car il fallait
écrire
define( "SCRIPT_FOLDER", "script");
puisqu'avant que la constante ne soit déclarée ici, elle n'existe pas,
il faut donc passer une chaîne.

C'est donc bien que je suis un boulet. Merci de l'info !

--
Nicolas Delsaux
JFS > Imaginer que des ingénieurs puissent reprendre le contrôle de quoi
que ce soit... Pas de doute, on est bien sur un forum de SF !
in fras en perte de contrôle

Si tu veux faire l'économie d'un isset() à un endroit où il sera inutile
hormis pour éviter la notice, tu fais:

$login = @$_POST['login'];

voila une reponse intelligente

rhaaaaaa...

je ne connaissais pas encore le hurlement du geek, merci pour cette demo
Aurelien :)

--
thibaut allender | freelance | web|system developer|designer
+32 496 26 75 76 | http://capsule.org

C'est ton probleme, rappel moi de ne jamais te demander de CV :)

blah blah blah
Passe deja ton bac avant de vouloir me demander mon CV (j'hesite pour le
smiley, aller j'en mets un double pour ne pas avoir un nouveau déprimé
sur les bras :))

Ce n'est pas pour coder proprement que je dis ca, je m'en fou
completement de la propreté de ce code, tend qu'il marche et qu'il est
sécurisé.

Ah.. La sécurité, nous y voila encore...

Et justement, l'erreur reporting sur E_ALL evite de se faire bananer


if(lalal){
$ok = TRUE;
}

if($ok){
// afficher les données banquaires de monsieur bidule
}

Et un petit script.php?ok=TRUE et tu te fait avoir. Alors que en
error_reporting E_ALL, tu auras un signalement de cette erreur et tu la
corrigeras.

Super... Et d'ou il sort le $ok ? apporté dans le script par pigeon
voyageur (c) j. gallet ?
Dans ton exemple, tu supposes que :
1) on est en register globals ON
2) le mechant hacker connait le nom de la variable a passer a TRUE (ce
qui voudrait dire qu'il a un mega bol de cocu, ou qu'il a acces au code
source)

Au sujet de ce genre d'erreur, pourquoi ne pas les corriger sur le tien ?

<b>Notice</b>: Undefined index: mail in
<b>/space_3/guillaum/guillaume/inc/add_reaction.inc.php</b> on line
<b>24</b><br />
<br />
<b>Notice</b>: Undefined index: pseudo in
<b>/space_3/guillaum/guillaume/inc/add_reaction.inc.php</b> on line
<b>30</b><br />

Et surtout, pourquoi conserver les messages d'erreur sur un serveur de
prod ? ce qui est le b.a.-ba de la sécurité...
tu parlais de CV uhm ?

On voie que tu n'est pas hasmatique.

C'est une nouvelle maladie ? :)

C'est à cause de comportements comme cela que le php à une reputation de
language de newbie plein de failles, merci.

C'est a cause des newbies qui l'utilisent, et qui font n'importe quoi.
Se mettre en error_reporting E_ALL ou en register_globals Off ne va pas
empecher un newbie de coder n'importe comment, et de rendre ses scripts
vulnerables... Avant, le newbie faisait include($toto); maintenant il
fait include($_GET['toto']). Moi je ne vois aucune amelioration niveau
sécurité, fais moi signe quand tu en verras une.

De toutes facons, j'attendais ce genre de reponse, tout comme ton
exemple de "sécurité" foireux.

--
thibaut allender | freelance | web|system developer|designer
+32 496 26 75 76 | http://capsule.org

Message d'origine de Thibaut Allender :

On voie que tu n'est pas hasmatique.

C'est une nouvelle maladie ? :)

À mon humble avis, il voulait dire "asthmatique".

C'est à cause de comportements comme cela que le php à une reputation
de language de newbie plein de failles, merci.

C'est a cause des newbies qui l'utilisent, et qui font n'importe quoi.
Se mettre en error_reporting E_ALL ou en register_globals Off ne va pas
empecher un newbie de coder n'importe comment, et de rendre ses scripts
vulnerables... Avant, le newbie faisait include($toto); maintenant il
fait include($_GET['toto']). Moi je ne vois aucune amelioration niveau
sécurité, fais moi signe quand tu en verras une.

Ben si, le fait d'être à register_globals à off apporte l'avantage dont
machin vient de te parler.
Une variable interne au script (qui sert pour des traitements, des
boucles ou que sais-je) peut être modifiée par GET dans le cas d'un
register_globals à on.
Le register_globals à off permet de restreindre les variables qu'envoie
l'utilisateur par HTTP à $_POST, $_GET ou $_SERVER, ce qui évite toute
interaction avec le script.
Bon, on pourra toujours dire que si on se débrouille bien, ça devrait
pas gêner. Mais il est impossible de considérer toutes les éventualités,
et c'est une perte de temps stupide.

Mais bon, là je parle de register_globals, pas de error_reporting.
Franchement, empêcher l'affichage des notice, c'est pas bien grave.
D'ailleurs c'est pour ça qu'on appelle ça des "Notice". C'est juste pour
signaler au codeur que ce qu'il fait c'est nul, mais que PHP dans sa
grande gentillesse va tout réparer tout seul. PHP est très laxiste, oui.

Bien évidemment, ça reste mieux de faire des choses qui ont du sens, en
vérifiant qu'une variable existe avant de l'utiliser.
Parce que sinon cela peut amener des résultats imprévisibles.

Bref, la sémantique, y'a que ça de vrai.

... ou qu'on se tape pas mal des notice
je prefere avoir un code "crade" que de le surcharger de isset() inutiles

Je suis partiellement d'accord. Ce qui me gave positivement ce sont les
notice sur les index de tableaux non définis. En revanche, les notice sur
les variables non initialisées peuvent être utiles.

qu'on utilise isset() ou le code "crade", le resultat est le meme :
$login ne vaudra rien

Pas nécessairement.

Pour moi il y a trois cas différents :
1) les variables externes ($_GET/POST/REQUEST)
Il est facile (et quasi incontournable) d'écrire une fonction/classe pour y
accéder de manière sécurisée. AU passage, tu lui donne une valeur par défaut
à affecter à la variable si elle n'a pas été transmise.
2) les variables non tableau utilisées de manière générale dans le code. Là,
les notice me sont utiles.
3) les index de tableaux. Parfois ils me sont utiles (faute de frappe)
parfois extrêmement casse couilles.

Exemple typique : utiliser le même code pour un formulaire qui permet ou de
faire une mise à jour ou l'ajout d'un enregistrement. Facile de gérer les
undefined pour la mise à jour, de toutes façons, ou on est dans le cas où
l'on va chercher les données en base ou dans celui où on les reçoit depuis
l'extérieur. Mais pour faire l'ajout, la première demande du formulaire
remplit bien à "" ou à 0 les champs obligatoires à la saisie, mais les
champs internes à la structure... C'est pas bien grave mais c'est illogique.

et je sais que ca va faire huler les geeks, mais chacun a sa facon de coder
si php tolere qu'on ne declare pas les variables ou qu'on utilise des
index inextistants, c'est pas pour rien.

Tout à fait d'accord pour les données "mortes" i.e. celles qu'on fait
transiter dans le programme pour simple stockage sgbd+affichage. Pour celles
qui participent à l'algorithme de traitement, c'est plus que discutable.

a++
JG

Ben si, le fait d'être à register_globals à off apporte l'avantage dont
machin vient de te parler.
Une variable interne au script (qui sert pour des traitements, des
boucles ou que sais-je) peut être modifiée par GET dans le cas d'un
register_globals à on.

oui, mais comme je l'ai dit, il faut deviner le nom des variables

Le register_globals à off permet de restreindre les variables qu'envoie
l'utilisateur par HTTP à $_POST, $_GET ou $_SERVER, ce qui évite toute
interaction avec le script.

merci pour cette relecture du manuel :)

Bon, on pourra toujours dire que si on se débrouille bien, ça devrait
pas gêner. Mais il est impossible de considérer toutes les éventualités,
et c'est une perte de temps stupide.

oui enfin, on ne va pas non plus se soucier de *toutes* les variables
tu parles de variable "qui sert pour des traitements, des boucles ou que
sais-je"
ca n'est pas vraiment sensible (sauf cas particulier)

les eventualités sont deja bcp moins nombreuses, et il est alors facile
de s'assurer que la variable qu'on traite ne vient pas de l'exterieur

Mais bon, là je parle de register_globals, pas de error_reporting.
Franchement, empêcher l'affichage des notice, c'est pas bien grave.

oui, c'est quand meme la discussion de depart, on ne va pas revenir une
Nieme fois sur la question du registrer_globals

D'ailleurs c'est pour ça qu'on appelle ça des "Notice". C'est juste pour
signaler au codeur que ce qu'il fait c'est nul, mais que PHP dans sa
grande gentillesse va tout réparer tout seul. PHP est très laxiste, oui.

nul, bof... combien de fois on ne voit pas de "warning" a la compilation
d'une source... c'est pas pour ca que ca ne fonctionne pas.

plus léché, plus sécurisé dans certains cas, oui, mais nul...

Bien évidemment, ça reste mieux de faire des choses qui ont du sens, en
vérifiant qu'une variable existe avant de l'utiliser.
Parce que sinon cela peut amener des résultats imprévisibles.

encore une fois, ca depend de la sensibilité de la variable qu'on utilise

--
thibaut allender | freelance | web|system developer|designer
+32 496 26 75 76 | http://capsule.org