Cross-Site Scripting : attention aux dégâts !
A l’origine, ces attaques cherchaient exclusivement à « voler » les cookies d’authentification. Mais avec la montée en puissance de Javascript, elles laissent désormais un intrus naviguer librement sur l’intranet.
Les attaques par Cross-Site Scripting (XSS) datent d’une dizaine d’années. A l’origine, les failles étaient exploitées dans le but presque exclusif de « voler » les cookies d’authentification. Par ce biais, un utilisateur malicieux pouvait accéder à une application web avec l’identité de la victime. Peu après sont arrivées d’autres formes d’exploitation, consistant à faire effectuer, à l’insu d’un utilisateur, un certains nombre d’opérations, en maintenant toujours ses droits sur l’application. Cette variante, appelée le Cross-Site Request Forgery (CSRF), est longtemps restée la forme d’exploitation la plus puissante de ce type d’attaque.
Un rapport impact/efficacité désormais avantageux
Relativement complexes à mettre en œuvre et nécessitant que l’utilisateur suive un lien malicieux, les Cross-Site Scripting n’offraient pas un rapport impact/efficacité avantageux. Ces attaques sont par conséquent restées à l’écart de la scène, alors que les SQL injections, erreurs logiques et autres dénis de service focalisaient toute l’attention des responsables de la sécurité. Et bien que l’Owasp* soit passé de la quatrième à la première place de son top 10 des XSS entre 2004 et 2007, la lutte contre le vol de cookies, maintenant chiffrés, ne semblait pas prioritaire.
C’était sans compter l’avènement du web 2.0 et la montée en puissance de Javascript. En effet, les fonctions toujours plus puissantes mises à disposition des développeurs du web profitent également à ceux qui cherchent à en abuser. Et lorsqu’un navigateur est suceptible d'être transformé en éditeur de texte, il peut également devenir un proxy vers le réseau local, laissé sans défense contre un ennemi venant de l’intérieur et se conformant strictement à la politique de sécurité. Un intrus peut ainsi naviguer librement sur les applications web du réseau interne, scanner les ports des serveurs, lancer un déni de service ou observer la navigation du client compromis, sans que ce dernier ne perçoive la moindre action illégitime.
Trois caractéristiques particulièrement efficaces
- L’obfuscation : l’attaque peut être masquée afin d’éviter la détection par des mécanismes de filtrage restés trop primitifs. Le XSS devient furtif et se cache dans les routines de gestion des erreurs, s’encode en base64, devient un événement de l’application et révèle les formes dépréciées d’appel aux fonctions.
- Le dynamisme : l’infection se propage seule, sans avoir besoin de s'appuyer, désormais, sur l’action imprudente d’un utilisateur. Elle est maintenant stockée dans la base de données. Lorsqu’un utilisateur accède à une page dont le contenu est généré à partir de cette donnée corrompue, le navigateur est instantanément compromis et tente de trouver une faille pour y insérer à nouveau le code malicieux. Une opération triviale lorsque les différents utilisateurs disposent de pages aux fonctions identiques, cas typique des réseaux sociaux.
- Le polymorphisme : les codes stockés en base de données changent de forme. La richesse de Javascript est telle que deux fonctions peuvent être écrites et représentées de différentes manières. La découverte d’une entrée malicieuse dans une base de données n’est donc plus synonyme de nettoyage rapide et automatisé des autres occurrences. Chaque entrée est maintenant différente. Ainsi sur une application très active, la propagation sera plus rapide que le nettoyage, devenu quasiment manuel et traité au cas par cas.
Trois critères et une richesse fonctionnelle qui font aujourd’hui du Cross-Site Scripting la base des nouveaux botnets. Des frameworks entiers apparaissent pour en accélérer l’écriture et l’exploitation, avec comme objectif une surface d’attaque aujourd’hui inégalée, l’ensemble des ordinateurs disposant d’un navigateur. La nouvelle génération de Cross-Site Scripting est, à juste titre, considérée comme le buffer overflow du XXIe siècle.
*L'Owasp (Open Web Application Security Project) est une fondation (au sens de l'administration fiscale américaine). Son objectif principal de l'Owasp est de produire des outils, des documents et des standards dédiés à la sécurité des applications web.