L'exécution de code JavaScript sur le poste client combiné aux transferts de données asynchrones sans confirmation ouvre assurément une brèche de sécurité. Le risque n'est pas tant sur le poste de travail, comme se plaît à le croire cet article alarmiste Ajax présente-t-il des risques ?. Après tout, le code JavaScript reste confiné dans sa sandbox, le risque n'est pas pire qu'avec une application JavaScript classique. Le danger concerne le serveur, et plus précisément les données qui transitent entre le client et le serveur. MySpace, site de réseau social et figure emblématique du Web 2.0, permet à un utilisateur d'ajouter dans son profile ses amis qui eux-mêmes peuvent s'ajouter les vôtres, et ainsi de suite. En octobre dernier, « Samy », un adolescent de 19 ans (rien à voir avec notre toulousain préféré) a eu l'idée d'exploiter la plate-forme Ajax pour se faire des amis. Après quelques bidouilles pour contourner le système de protection de MySpace contre l'exécution de code JavaScript, Samy a créé un code JavaScript sur sa page MySpace qui s'exécute automatiquement dès qu'un utilisateur visite son profile. Comme JavaScript permet d'exécuter des confirmations en tâche de fond, ce code rajoute Samy comme ami dans le profile du visiteur. Puis le code se duplique lui-même dans le profile du visiteur, de telle sorte que les visiteurs de ce profile exécutent le même code et le propagent de profiles en profiles. En moins de 20 heures d'activité, le ver avait créé 1 million d'amis à Samy. Quelques heures après, il écroulait le site MySpace. Depuis, Samy est grillé chez MySpace, mais il a publié sur son site I'm Popularle source de son programme maintenant inopérant et relate force détails de son « exploit ». Baptisé MySpace Worm ou Samy Worm, ce virus n'a causé finalement aucun dommage. Cette semaine, Yamanner, un nouveau ver utilisant une technique similaire, est apparu sur le webmail de Yahoo!, autre grande plate-forme Ajax. Contrairement aux autres vers se propageant par email, le code du script n'est plus attaché dans une pièce jointe qu'il faut ouvrir pour exécuter le code, mais il est embarqué dans le corps même du message HTML et s'exécute dès la prévisualisation du message. Il envoie alors le même mail à tous les contacts du carnet d'adresses qui eux-mêmes, en l'ouvrant, propageront le ver. Yamanner envoie également une copie des contacts sur un serveur externe non encore identifié, sans doute à des fins de spamming selon les experts en sécurité. Yahoo Mail a limité l'usage d'Ajax strictement aux interactions entre l'utilisateur et les serveurs de Yahoo, mais Yamanner a exploité une des rares fonctions JavaScript que Yahoo Mail n'avait pas blindées, la possibilité d'exécuter un JavaScript quand une image est uploadée à partir d'un message. Le ver a substitué son propre JavaScript quand le code de téléchargement de l'image s'est lancé. Ces deux exemples illustrent la possibilité d'exécuter un code JavaScript embarqué dans une page. Ce type de virus appelé Cross-Site Scripting (XSS pour les spécialistes) est en général utilisé pour voler des données et usurper des identités (phishing). Ce qu'il y a de nouveau, c'est que ces scripts exploitent l'asynchronicité d'Ajax pour s'exécuter en tâche de fond, sans confirmation. Si l'on peut aisément imaginer les domaines d'applications de tels scripts, les pirates se feront une joie de trouver des domaines auxquels vous n'aviez même pas pensés. Le danger peut aussi venir de l'intérieur. Un code Ajax mal contrôlé peut envoyer à son propre serveur des requêtes à l'infini, créant ainsi un auto déni de service. Les développeurs qui veulent se lancer dans Ajax devront au préalable identifier les risques qui peuvent tous être évités. L'application serveur doit s'assurer que les requêtes XmlHttpRequest qu'il reçoit proviennent bien de l'application Ajax déployée, en cryptant la session par exemple. Un pattern proxy pourra être utilisé pour les interactions AjAX avec des services externes. Pour détecter d'éventuelles failles de sécurité, il existe maintenant Sprajax, un outil Open Source édité par Denim Group (www.denimgroup.com/Sprajax/). Il est annoncé comme le premier scanner de sécurité web spécifiquement conçu pour détecter les failles de sécurité dans les applications AJAX. D'après les premiers retours d'expérience, cet outil n'est compatible qu'avec le framework Atlas et qu'il ne scanne pas dans les fichiers JavaScript les requêtes XmlHttpRequest. Selon Dietrich Kappe sur son blog, le marketing autour de ce produit est un peu exagéré, tout ce qu'il fait pourrait être écrit en Perl en quelques heures. Mais c'est un début, un projet à surveiller.