Sauf que Cédric, il t'as indiqué de mettre le sql_quote dans la requête et non avant pour pouvoir envisager un audit de code automatique...
Ah bon ? Je l'avais pas compris comme ça.
Je cite :
«
Une bonne règle que j'applique systématiquement est de *toujours* protéger chaque variable PHP qui apparait dans un sql_xx, et ce, même si la variable a subi un intval 2 lignes plus tôt.
Cela permet de voir immédiatement qu'une requête est sûre, sans avoir à lire le code en amont.
Et ça ouvre la porte à des outils de verif automatisés.
»
Sans avoir à lire le code en amont me fait comprendre que le sql_quote est donc dans la même ligne.
Pourquoi le faire dès le début empêcherait cet "audit de code automatique" ? En quoi consisterait-il ?
No sé. Je ne fais qu'exprimer ma compréhension de la citation.
Sans avoir à lire le code en amont me fait comprendre que le sql_quote est donc dans la même ligne.
c'est surtout que tu sql_quote *dans* un sql_xx et *pas* dans un sql_xxq
or si tu as sql_quote ta variable préalablement, comment savoir au moment de son insertion dans le sql_xxq qu'il va y avoir un problème ?
c'est surtout que tu sql_quote *dans* un sql_xx et *pas* dans un sql_xxq
or si tu as sql_quote ta variable préalablement, comment savoir au moment de son insertion dans le sql_xxq qu'il va y avoir un problème ?
c'est surtout que tu sql_quote *dans* un sql_xx et *pas* dans un sql_xxq
or si tu as sql_quote ta variable préalablement, comment savoir au moment de son insertion dans le sql_xxq qu'il va y avoir un problème ?
Sauf que Cédric, il t'as indiqué de mettre le sql_quote dans la requête et non avant pour pouvoir envisager un audit de code automatique...
Ah bon ? Je l'avais pas compris comme ça. Pourquoi le faire dès le début empêcherait cet "audit de code automatique" ?
Parce que, comme je le disais :
si tu protege à chaque fois dans l'appel a sql_xx, il suffit de lire l'appel a sql_xx pour voir qu'il est protégé et sur, sinon il faut remonter le code pour trouver les variables. A l'usage il est beaucoup plus simple et rapide de ne pas à avoir à comprendre le code pour savoir qu'il est sur.
Dans le cadre d'un outil automatisé, protéger les variables dans l'appel a sql_xx permet aussi une vérification auto par un simple grep en checkant simplement que chaque variable apparait bien protégée dans l'appel de la fonction.
Sinon, cela suppose une analyse syntaxique en amont, c'est beaucoup plus lourd.
Le 3 juil. 09 à 10:07, cedric.morin@yterium.com a écrit :
Parce que, comme je le disais :
si tu protege à chaque fois dans l'appel a sql_xx, il suffit de lire l'appel a sql_xx pour voir qu'il est protégé et sur, sinon il faut remonter le code pour trouver les variables. A l'usage il est beaucoup plus simple et rapide de ne pas à avoir à comprendre le code pour savoir qu'il est sur.
Dans le cadre d'un outil automatisé, protéger les variables dans l'appel a sql_xx permet aussi une vérification auto par un simple grep en checkant simplement que chaque variable apparait bien protégée dans l'appel de la fonction.
Sinon, cela suppose une analyse syntaxique en amont, c'est beaucoup plus lourd.
