Contribuez à SecuObs en envoyant des bitcoins ou des dogecoins.
Nouveaux articles (fr): 1pwnthhW21zdnQ5WucjmnF3pk9puT5fDF
Amélioration du site: 1hckU85orcGCm8A9hk67391LCy4ECGJca

Contribute to SecuObs by sending bitcoins or dogecoins.



[Sécurité avec Microsoft Internet Explorer – Partie 4] Cascading Style Sheets Cross Site Scripting ou CSSXSS

Par Krysztof Kozlowski, hakin9
Le 22/10/2007


Résumé : Découvrez ou redécouvrez dans cette partie les détails et principes des attaques de type Cascading Style Sheets Cross Site Scripting qui exploitent conjointement des failles de type XSS avec les fonctionnalités d'importation des feuilles de style CSS pour le web.



Les navigateurs étaient restreints en ce qui concernait les interactions liées à plusieurs domaines. Une page spécifique forgée à l'avance pouvait alors permettre de rediriger l'utilisateur vers une autre adresse que celle à laquelle il se destinait initialement. Celle-ci ne pouvait toutefois pas en l'état le forcer à elle seule à lire son contenu ou à faire manipuler un objet DOM ( lien ) ; cette restriction était bien effective et donc le propriétaire de la page ne pouvait pas espionner l'internaute à l'aide de script de type JavaScript.

Cependant si l'utilisateur était authentifié à un service donné (gmail, hotmail, ...) sans ces protections, la page visitée pouvait alors effectuer des opérations sur le compte de l'utilisateur (par exemple, supprimer les messages ou les envoyer à un email tiers). Avec Internet Explorer, ces protections fonctionnaient bien tant que les importations CSS n'entraient pas en jeu.

On appelle couramment les attaques liées à ces importations des attaques de type CSSXSS ( Bulletin de sécurité Microsoft MS06-21 - lien ) ou Cascading Style Sheets Cross Site Scripting de son petit nom ; une page préalablement forgée spécifiquement pouvait importer les règles CSS à l'aide de la directive @import dans un premier temps. Microsoft Internet Explorer était doté d'une autre fonction bien pratique disponible au niveau du langage Javascript, la fonction addImport qui fonctionnait sensiblement à la manière de la fonction @import ; les règles CSS pouvaient alors ensuite servir à accéder aux propriétés cssText dans l'ensemble document.styleSheets afin de les manipuler.


Que se passait-t-il toutefois si la page importait une adresse URL qui n'était pas un fichier CSS valide ?

Microsoft Internet Explorer permettait de transformer CSS et de lire les propriétés cssText tout en consultant à distance le code HTML chargé par les règles CSS ; puisque les règles CSS nécessitaient une certaine structure pour une quantité de code appropriée, ce code pouvait donc se différencier en fonction de la source de la page.

Les règles CSS déterminaient l'aspect des pages HTML et définissaient en général le choix, la propriété et les valeurs à y affecter. La propriété et les valeurs étaient séparées par les deux points et fermées par des parenthèses ; à titre d'exemple, pour colorer les liens d'une page, il fallait définir la règle CSS : a {color: white} ici pour des liens en blanc. Afin de récupérer le code d'une adresse donnée qui fournissait un code CSS incorrect, la page cible devait contenir quelques caractères spéciaux utilisés en CSS, par exemple des parenthèses.

De nombreuses pages les contenaient et les contiennent toujours ces caractères ils sont très populaires dans l'utilisation de code Javascript et des règles CSS elles-mêmes implémentées sur ces pages. Dès que le parseur CSS de Microsoft Internet Explorer trouvait les parenthèses appropriées, il essayait de lire les données et de les interpréter ainsi que celles se trouvant juste derrière. Même si ces règles CSS n'avaient aucun sens, Microsoft Internet Explorer les interprétait quand même toujours et il permettait de les voir au niveau cssText.

Les différentes combinaisons de parenthèses, de deux-points et de points-virgules permettaient de décider quels fragments du code pouvaient être lus ou pas. Lors de l'utilisation des techniques CSSXSS, l'attaquant essayait d'exécuter cette attaque par le code JavaScript directement mais il pouvait également s'aider d'une technique consistant à injecter des caractères CSS dans l'espace cible de l'adresse. Puisque de nombreuses pages étaient générées dynamiquement et obtenaient les paramètres via l'URL, l'injection de caractères était alors très simple à réaliser.

Ce mécanisme ressemblait à celui utilisé dans les attaques XSS traditionnelles ( lien ) à cette différence près que l'attaquant injectait ici des caractères qui étaient considérés par la plupart des pages comme inoffensifs. De même que la plupart des failles XSS, les erreurs dans la conception même de Microsoft Internet Explorer permettaient à l'attaquant d'intercepter des données privées ou d'exécuter un code malicieux sur un ordinateur distant.

La différence, dans ce cas-là, consistait en fait à ce que la page ne devait pas être sujette à l'injection de code ; tout ce que l'attaquant devait faire était d'inviter la victime à venir sur une page spécifique préalablement forgée. Des pages de nombreux sites pouvaient être alors utilisées car aucune solution simple n'existait afin de se protéger de ces attaques tant que les failles d'Internet Explorer n'étaient pas réparées ; cela impliquait de nombreux utilisateurs susceptibles d'être attaqués.

Cette vulnérabilité avait été testée sur le navigateur Internet Explorer en version 6, les navigateurs plus anciens étaient probablement aussi faillibles. Pour comparer, le navigateur Mozilla Firefox semblait respecter les restrictions et les conserver lors des importations CSS ; ce qui le rendait plus résistant à ce type d'attaques. Le navigateur Opera n'était pas vulnérable puisqu'il ne supportait tout simplement pas la série styleSheets. Les utilisateurs pouvaient cependant se protéger en désactivant l'exécution du Javascript dans Microsoft Internet Explorer ou en utilisant un autre navigateur.


NB : Il est possible de s'abonner au magazine Hakin9 et d'acheter directement le dernier numéro ou d'anciens numéros, en cliquant sur l'image ci-dessous :

Software-Wydawnictwo



Autres ressources dans ce dossier :

[Sécurité avec Microsoft Internet Explorer – Partie 1] Introduction et rappel – lien

[Sécurité avec Microsoft Internet Explorer – Partie 2] Présentation et statistiques - lien

[Sécurité avec Microsoft Internet Explorer – Partie 3] Attaques sur l'application Google Desktop - lien

[Sécurité avec Microsoft Internet Explorer – Partie 5] Exploitation de Google Desktop et exécution distante de code - lien

[Sécurité avec Microsoft Internet Explorer – Partie 6] Prise de contrôle du filtre d'exceptions critiques - lien

[Sécurité avec Microsoft Internet Explorer – Partie 7] Crédits & références - lien