Donc en ce cas, la solution 3/ est à bânir. Le navigateur peut juste filtrer par les méthodes 1/ et 2/ (même si le script est intégré dans la page "graphiquement", il n'est pas exécuté, juste affiché, donc le navigateur peut faire la différence et la méthode 2/ ne bloque donc pas ce type d'utilisation).
Mais je vois d'autres problèmes.
Par exemple, imaginons qu'on veuille justement désactiver, mais partiellement seulement, certaines parties d'un script inclus dans une page et que cela permette d'en changer le sens (et obtenir même un usage néfaste), on pourrait alors:
- inclure dans une url une variable contenant la copie de la partie du script à virer (que l'on sait sera incluse dans la page retournée).
- Le serveur lui en réalité ne connaît pas cette variable bidon, n'en prendra pas compte et retournera la page normalement.
- Le navigateur ne sait pas ce que fait ou non le serveur en interne, bien évidemment, par contre il reconnaît que le bout de script qu'il a vu dans l'url se retrouve dans la page comme code à exécuter. Il en conclut "intelligemment" qu'il s'agit sûrement d'une faille de cross scripting et que ce code a été injecté (alors qu'il n'en est rien, il n'y a aucune corrélation réelle entre l'url et ce script).
- Le navigateur retire ce bout de script, mais s'il exécute le reste, ça peut devenir dangereux (si ça a été pensé pour l'être).
Donc ici on a généré une attaque en faisant croire au système de protection qu'il y avait une autre attaque! Ainsi il faut faire très gaffe aussi avec ce genre de sécurité intelligente qui peuvent elle-même créer des failles là où il n'y en avait pas auparavant.
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é à 3.
Donc en ce cas, la solution 3/ est à bânir. Le navigateur peut juste filtrer par les méthodes 1/ et 2/ (même si le script est intégré dans la page "graphiquement", il n'est pas exécuté, juste affiché, donc le navigateur peut faire la différence et la méthode 2/ ne bloque donc pas ce type d'utilisation).
Mais je vois d'autres problèmes.
Par exemple, imaginons qu'on veuille justement désactiver, mais partiellement seulement, certaines parties d'un script inclus dans une page et que cela permette d'en changer le sens (et obtenir même un usage néfaste), on pourrait alors:
- inclure dans une url une variable contenant la copie de la partie du script à virer (que l'on sait sera incluse dans la page retournée).
- Le serveur lui en réalité ne connaît pas cette variable bidon, n'en prendra pas compte et retournera la page normalement.
- Le navigateur ne sait pas ce que fait ou non le serveur en interne, bien évidemment, par contre il reconnaît que le bout de script qu'il a vu dans l'url se retrouve dans la page comme code à exécuter. Il en conclut "intelligemment" qu'il s'agit sûrement d'une faille de cross scripting et que ce code a été injecté (alors qu'il n'en est rien, il n'y a aucune corrélation réelle entre l'url et ce script).
- Le navigateur retire ce bout de script, mais s'il exécute le reste, ça peut devenir dangereux (si ça a été pensé pour l'être).
Donc ici on a généré une attaque en faisant croire au système de protection qu'il y avait une autre attaque! Ainsi il faut faire très gaffe aussi avec ce genre de sécurité intelligente qui peuvent elle-même créer des failles là où il n'y en avait pas auparavant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]