-----Message d'origine-----
De : "Déesse A." [mailto:esj@rezo.net]
Envoyé : jeudi 20 avril 2006 14:26
À : Lefebvre Christian
> je me suis dit qu'il
> serait peut être
> pertinent d'avoir une fonction spip_escape_string qui appelle
> mysql_real_escape_string
Je ne suis pas sûr. Je viens de faire des contournements pas
possibles pour que le critère IN accepte qu'un paramètre HTTP soit
un tableau, tout en neutralisant un XSS qui pourrait s'y trouver.
Je comprend pas trop le rapport.
Ce que je propose, c'est juste de remplacer les 493 appels existant à addslashes par
des appels à spip_escape_string qui embalerait mysql_real_escape_string.
Comme ça, s'il existe un postgres_espace_string qui n'a pas le même comportement,
il sera facile de l'utiliser dans un futur db_postgres par exemple.
Ce que je propose, c'est juste de remplacer les 493 appels existant à
addslashes par des appels à spip_escape_string qui embalerait
mysql_real_escape_string.
En fait dans mon idée on aurait à terme une écriture du style
query("requete virtuelle '%s'", contenu)
et query() se débrouillerait pour passer la bonne fonction. Les rares cas où
ça n'est pas possible, je mettrais l'échappement dans la fonction query()
comme par exemple :
query("SELECT * WHERE contenu='"._e($contenu)."'")
Il faut donc en profiter pour revoir toutes les query.
Sinon je ne suis pas contre ce que tu dis, mais :
- avec un autre nom (celui que tu proposes est impossible à mémoriser et à
taper) ; je propose _e() par exemple.
- la fonction doit être accessible de partout, sinon il faut inclure
inc_db_xxx systématiquement, ce qui pose un risque d'erreur ; mais il y
aura une difficulté à l'articuler avec du multibase...
Bref, le "juste remplacer" n'est pas si élémentaire que ça
Il y a déjà un pb ici, parce qu'il n'y a pas toujours de correspondance bijective entre une requete MySQL et une requete PG, SQLite ou autre. Par exemple la premiere abstraction que j'ai du faire est pour le insert, car MySQL permet de connaitre par la suite l'ID créé, tandis que pour PG on doit le donner d'abord. Avoir une seule fonction de requete n'est donc pas bon, car ça oblige à refaire une analyse syntaxique (et en particulier repérer les ' et autre \) pour aller prélever les éléments qu'il faut. Il faut plusieurs fonctions, avec abstraction des arguments des clauses, et tout centraliser dans différentes instances de abstract_sql.php. C'est pour ça que presque tous les appels à spip_query ont été réécrits sous la forme spip_query("....) et plus aucun spip_query($...) afin à terme de différencier chacun des appels.
Alors Christian, si tu as de l'énergie à revendre en ce qui concerne mysql, il reste encore 10 appels spip_query($...), qui tourne autour de l'embrouillamini nommé tranches_requete qu'il faut réécrire.
Je t'en souhaite !
-----Message d'origine-----
De : "Déesse A." [mailto:esj@rezo.net]
Envoyé : jeudi 20 avril 2006 14:26
À : Lefebvre Christian
je me suis dit qu'il serait peut être
pertinent d'avoir une fonction spip_escape_string qui appelle mysql_real_escape_string
Je ne suis pas sûr. Je viens de faire des contournements pas possibles pour que le critère IN accepte qu'un paramètre HTTP soit un tableau, tout en neutralisant un XSS qui pourrait s'y trouver.
Je comprend pas trop le rapport.
Moi non plus je ne comprends pas l'objection.
Ce que je propose, c'est juste de remplacer les 493 appels existant à addslashes par
des appels à spip_escape_string qui embalerait mysql_real_escape_string.
Comme ça, s'il existe un postgres_espace_string qui n'a pas le même comportement,
il sera facile de l'utiliser dans un futur db_postgres par exemple.
Pour SQLite ça me paraît indispensable :
"The SQL standard specifies that single-quotes in strings are escaped by putting two single quotes in a row. SQL works like the Pascal programming language in the regard. SQLite follows this standard."
Ce qui a été fait sur la maquette Spip/SQLite:
pas de de "de-quotage" sur un SELECT. Ajout stripslashes() sur spip_auteurs prefs.
on remplace addslashes() par un str_replace ("'","''") au niveau de l'import ==> a generaliser....
Il y a environ 200 appels; donc je suis pour la proposition de Piif. Sinon quelle serait l'alternative ?
je me suis dit qu'il
serait peut être
pertinent d'avoir une fonction spip_escape_string qui appelle
mysql_real_escape_string
Je ne suis pas sûr. Je viens de faire des contournements pas
possibles pour que le critère IN accepte qu'un paramètre HTTP soit
un tableau, tout en neutralisant un XSS qui pourrait s'y trouver.
Je comprend pas trop le rapport.
Moi non plus je ne comprends pas l'objection.
Peut-etre que je ne comprend pas bien l'enjeu, mais mon réflexe est d'éviter à quiconque de se payer un patch de 500 lignes qui risque d'etre inexploitable car ce code bouge beaucoup en ce moment: le but des préparatifs de la tache #209 est de remplacer spip_query par des appels aux fonctions d'abstractions spip_abstract_select, spip_abstract_insert etc. Tant que ceci ne sera pas achevé, un patch sur ces appels sera du travail perdu.
Peut-etre que je ne comprend pas bien l'enjeu, mais mon réflexe est d'éviter à quiconque de se payer un patch de 500 lignes qui risque d'etre inexploitable car ce code bouge beaucoup en ce moment: le but des préparatifs de la tache #209 est de remplacer spip_query par des appels aux fonctions d'abstractions spip_abstract_select, spip_abstract_insert etc. Tant que ceci ne sera pas achevé, un patch sur ces appels sera du travail perdu.
Effectivement et c'est tout le problème de la maquette Spip/SQLite. Il y a maintenant plus de 30 fichiers modifiés pour 1500 lignes de patch, et potentiellement beaucoup plus (sur la base du noyau actuel). Pour certaines fonctions, aller plus loin serait du travail perdu pour pas ou peu d'enseignements à tirer.
Pour d'autres aspects, il y a probablement encore des découvertes à faire; je prévois de proposer bientôt une maquette SQLite capable d'importer une base consistante et de l'afficher en public au moins avec les squelettes dist et Epona. S'il y a des volontaires pour tester, par exemple avec un autre squelette, je peux fournir un zip complet.