la page renvoyée par spip exécute le javascript en question. Pour ce que
j'en ai compris, ça peut être exploité par un site tiers, de la façon
suivante :
A = site web de l'attaquant
S = site spip visé
C = client victime
C se connecte sur A (via une image insérée dans un forum sur S, par
exemple), qui le renvoie vers S?recherche=script_xxxxxxx
Le script_xxx est un javascript qui prend le cookie de C sur S, et conduit C
à faire un hit sur une url dans le domaine A. Du coup A peut lire le cookie
de C sur S.
Dans le cas du formulaire recherche, c'est simplement parce que dans
les squelettes on faisait <?php echo $recherche; ?> sans passer par
le propre()... Du coup le <script> n'était pas dégagé par la sécu
anti-script.
J'ai ajouté un #RECHERCHE qui contient le $recherche pour éviter ce
genre de blagues (bien que je ne voie pas réellement le problème).
On peut remplacer par #REQUETE_RECHERCHE si ça paraît trop ambigu.
Du reste les cookies SPIP sont censés être blindés contre les vols
de cookie, non ?
J'ai ajouté un #RECHERCHE qui contient le $recherche pour éviter ce
genre de blagues (bien que je ne voie pas réellement le problème).
On peut remplacer par #REQUETE_RECHERCHE si ça paraît trop ambigu.
Non, #RECHERCHE c'est pas mal.
Du reste les cookies SPIP sont censés être blindés contre les vols
de cookie, non ?
Certes, mais il y a des tas d'exploits à faire en dehors du vol de cookie,
d'après l'article mentionné... Mais bon, tout ça n'est pas très grave.
