Les failles XSS de la brise à l’Ouragan
Parfois anodine et peu connu des internautes, ces failles permettent bien souvent d’accéder à des données personnels de l’utilisateur dans des scenario aboutis. Pour autant cette vulnérabilité n’est pas récente, c’est là que le paradoxe prends son sens.
Mais qu’est ce que le XSS ?
Le XSS, de l’anglais cross site scripting, consiste à injecter et faire interpréter ou mieux, faire exécuter du code non attendu à un navigateur web. De cette définition, on peut en déduire que l’attaque ne se situe pas du côté du serveur mais plus plutôt du côté client, en d’autres termes une action du client final est nécessaire. Donc nous avons un aspect ingénierie sociale. De plus, ce genre d’attaque ne se limite pas à un langage. Tout langage reconnu par votre navigateur peut être exploité. C’est pourquoi les failles XSS sont souvent basées sur de l’HTML et du Javascript. Pour finir la première partie de sensibilisation, la vulnérabilité XSS figurait à la première place du top ten de l’OWASP en 2007. En 2010 il occupe la seconde place.
Prenons un exemple concret, vous recevez un mail de votre banque qui vous indique que de nouveaux documents sont disponibles à partir de votre compte et ils vous donnent un lien pour accéder aux ressources. En tant qu’utilisateur vous ne fait pas attention à l’url caché derrière le nom du lien et vous cliquez pour accéder à vos documents. A ce moment précis le mal est fait ! Vous ne vous êtes rendu compte de rien du tout mais votre requête à été intercepté par un autre site qui a volé vos identifiant de votre banque. Vous n’avez rien remarqué car vous avez été redirigé. Ce scenario semble sortir tout droit d’un James Bond, malheureusement, il est bien plus probable qu’un des scénarios de James Bond. Bien entendu, il y a quelques conditions. Ce scénario considère que le site de votre banque contient un champ vulnérable aux attaques XSS, que l’attaquant connaisse votre adresse mail, et qu’il ait un serveur distant ou il pourra stocker vos identifiants de connexion. Il est considéré également pour acquis que vos identifiants soit stockés dans un cookie. Vous me direz que cela fait beaucoup de conditions, même si la dernière est peu répandu (surtout pour un site bancaire) les autres conditions sont facilement réalisables.
Voici une schématisation du scénario énoncé.
Alors comment fonctionne concrètement cross site scripting, et bien la syntaxe la plus connue est l’exécution dans un champ non validé du code suivant :
Il a pour but une fois interprété par votre navigateur, d’afficher la pop up suivante :
C’est exemple est souvent utilisé comme PoC (Proof of Concept). Mais il existe beaucoup plus de combinaison possible. Ce billet n’a pas pour vocation de faire une liste exhaustive des éléments à parser dans vos champs. Il existe de très bonnes sources si vous cherchez ce genre d’information, comme par exemple le site ha.ckers.org. Cependant il faut comprendre que ce genre d’attaque est bien plus dangereuse pour l’utilisateur final que pour les serveurs. Grâce à l’utilisation de champ ou de paramètre non validé, il est possible également de ré-écrire une page web (via l’API DOM). Je vous invite à lire l’article de Pierre Gardenat qui a été publié récemment dans le magazine français MISC (édition Mai/Juin 2010). L’article est très bien détaillé. Je me suis permis de reprendre son titre que j’aime beaucoup. J’espère qu’il ne m’en voudra pas.