Psychofox, justement le script ne vient pas d'une autre machine. Je sais que l'explication est assez technique donc difficile à comprendre mais c'est ce que j'explique dans mon message plus haut.
Le script est injecté dans la page (par une url dans ce cas, mais d'autres méthodes sont envisageables), de sorte qu'il est tout à fait envisageable que le serveur lui-même sert la page avec le script inclus dedans. Là encore, les deux sont possibles. On pourrait aussi imaginer que le script est inséré côté client, par exemple si les variables url sont parsées par du javascript, qui à son tour exécute des scripts qui y sont passés. Mais le cas où l'url est parsée côté serveur et donc que ce dernier sert une page avec le script dedans est tout à fait probable. Dans l'attaque en question, rien n'est précisé sur la méthode exacte du cross scripting (encore une fois, ils attendent probablement que la faille soit comblée).
Par conséquent, d'un point de vue purement basique techniquement, le script ne vient pas d'une autre machine: il vient du serveur.
Cependant il est clair que toute méthode impliquant un script (donc une exécution sur machine) passable par url est mauvaise par design (franchement! Non?). Et comme je soulignais, le navigateur peut sûrement détecter ce genre d'anomalie, mais ce n'est pas du tout un truc évident, car de manière générale, il n'y a pas de bug technique, mais un "bug humain". On demande au navigateur là de repérer et protéger une grosse erreur du développeur (= accepter du code exécutable dans l'url sans protection particulière, l'équivalent d'utiliser la fonction "system" dans un programme sans aucune vérification, et pour une exécution de code très sensible). Néanmoins comme dans ce cas, il y a peu de chances que ça soit bien utilisé, on peut essayer...
Perso, je vois ca ainsi:
1/ si le script est intégré côté client, on peut repérer ça facilement et donc bloquer un tel script.
2/ sinon (intégré côté serveur), on peut essayer de repérer des familiarités entre les scripts intégrés dans la page et ce qui est passé en url. C'est apparemment ce que fait IE8beta2 par exemple (lien très intéressant donné par PasBill PasGate ci-dessous).
3/ de manière générale et plus simple, je me demande s'il ne faut pas virer de l'url tout ce qui ressemble à un script avant même de faire la requête au serveur. Comme je disais, je ne vois pas de bon usage, et même si le script n'est pas intégré dans la page en réponse, rien ne dit qu'il n'est pas exécuté sur le serveur lui-même et peut donc s'avérer très dangereux là-bas.
Néanmoins cela pose la question: jusqu'où «l'intelligence» (au sens IA) du navigateur doit aller pour protéger les erreurs de développement? Et qui sait si — en faisant cela — on ne bloque pas aussi des requêtes légitimes (contre toute attente, il existe peut-être de bons usages, même si je ne les vois pas dans l'immédiat, avec des serveurs qui vérifient et traitent le script au préalable par exemple pour en faire quelque chose d'adéquat, ou le supprimer si dangereux).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 4.
Le script est injecté dans la page (par une url dans ce cas, mais d'autres méthodes sont envisageables), de sorte qu'il est tout à fait envisageable que le serveur lui-même sert la page avec le script inclus dedans. Là encore, les deux sont possibles. On pourrait aussi imaginer que le script est inséré côté client, par exemple si les variables url sont parsées par du javascript, qui à son tour exécute des scripts qui y sont passés. Mais le cas où l'url est parsée côté serveur et donc que ce dernier sert une page avec le script dedans est tout à fait probable. Dans l'attaque en question, rien n'est précisé sur la méthode exacte du cross scripting (encore une fois, ils attendent probablement que la faille soit comblée).
Par conséquent, d'un point de vue purement basique techniquement, le script ne vient pas d'une autre machine: il vient du serveur.
Cependant il est clair que toute méthode impliquant un script (donc une exécution sur machine) passable par url est mauvaise par design (franchement! Non?). Et comme je soulignais, le navigateur peut sûrement détecter ce genre d'anomalie, mais ce n'est pas du tout un truc évident, car de manière générale, il n'y a pas de bug technique, mais un "bug humain". On demande au navigateur là de repérer et protéger une grosse erreur du développeur (= accepter du code exécutable dans l'url sans protection particulière, l'équivalent d'utiliser la fonction "system" dans un programme sans aucune vérification, et pour une exécution de code très sensible). Néanmoins comme dans ce cas, il y a peu de chances que ça soit bien utilisé, on peut essayer...
Perso, je vois ca ainsi:
1/ si le script est intégré côté client, on peut repérer ça facilement et donc bloquer un tel script.
2/ sinon (intégré côté serveur), on peut essayer de repérer des familiarités entre les scripts intégrés dans la page et ce qui est passé en url. C'est apparemment ce que fait IE8beta2 par exemple (lien très intéressant donné par PasBill PasGate ci-dessous).
3/ de manière générale et plus simple, je me demande s'il ne faut pas virer de l'url tout ce qui ressemble à un script avant même de faire la requête au serveur. Comme je disais, je ne vois pas de bon usage, et même si le script n'est pas intégré dans la page en réponse, rien ne dit qu'il n'est pas exécuté sur le serveur lui-même et peut donc s'avérer très dangereux là-bas.
Néanmoins cela pose la question: jusqu'où «l'intelligence» (au sens IA) du navigateur doit aller pour protéger les erreurs de développement? Et qui sait si — en faisant cela — on ne bloque pas aussi des requêtes légitimes (contre toute attente, il existe peut-être de bons usages, même si je ne les vois pas dans l'immédiat, avec des serveurs qui vérifient et traitent le script au préalable par exemple pour en faire quelque chose d'adéquat, ou le supprimer si dangereux).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]