Une attaque Cross-Site Scripting basée sur DOM est le nom de facto pour les bogues XSS qui sont le résultat de contenu actif d'une page côté client, typiquement JavaScript récupère l'entrée de l'utilisateur, puis produit du contenu dangereux avec celle-ci ce qui conduit à l'exécution du code injecté. Ce document ne traite que des bugs javascript qui conduisent à des attaques XSS.

Le DOM ou Document Object Model, est le format de structure utilisé pour représenter des documents dans un navigateur. Le DOM permet aux scripts dynamiques tels que JavaScript de faire référence à des composants de documents comme un champ de formulaire ou un cookie de session. Le DOM est également utilisé par le navigateur pour la sécurité - par exemple pour limiter sur différents domaines l'obtention des cookies de session d'autres domaines. Une vulnérabilité XSS basée sur DOM peut se produire lorsque le contenu actif, comme une fonction JavaScript, est modifié par une requête spécialement conçue de telle sorte qu'un élément DOM puisse être contrôlé par un attaquant.

Il y a eu très peu de documents publiés sur ce sujet et, à ce titre, très peu de normalisation et de test formalisé existent.

Tous les bugs XSS ne nécessitent pas que l'attaquant contrôle le contenu retourné par le serveur, mais peuvent abuser de mauvaises pratiques de codage JavaScript pour atteindre les mêmes résultats. Les conséquences sont les mêmes qu'une faille XSS typique, seulement le moyen d'y parvenir est différente.

En comparaison à d'autres Vulnérabilités Cross Site Scripting (reflected et stocked), où un paramètre non filtré est passé par le serveur, renvoyé à l'utilisateur et exécuté dans le contexte du navigateur de l'utilisateur, une vulnérabilité XSS basée sur DOM commande le flot de données du code à l'aide des éléments du Document Object Model (DOM) afin que le code élaboré par l'attaquant modifie le flux.

En raison de leur nature, les vulnérabilités XSS basées sur DOM peuvent être exécutées dans de nombreux cas sans que le serveur soit en mesure de déterminer ce qui est réellement exécuté. Cela peut rendre beaucoup de techniques de filtrage et de détection de XSS impuissantes à de telles attaques.

Le premier exemple hypothétique utilise le code côté client suivant:

<script>
 document.write("Site is at: " + document.location.href + ".");
 </script>

Un attaquant peut ajouter <yamdwenowiki>0</yamdwenowiki> à l'URL de la page concernée qui, lorsqu'il est exécuté, affiche un message d'alerte. Dans ce cas, le code ajouté n'est pas envoyé au serveur car tout ce qui suit le caractère # n'est pas considéré comme faisant partie de la requête par le navigateur mais comme un fragment. Dans cet exemple, le code est exécuté immédiatement et une alerte de “xss” est affichée par la page. Contrairement aux types les plus courants de cross-site scripting (stocked ou reflected) dans lesquels le code est envoyé au serveur, puis vers le navigateur, il est exécuté directement dans le navigateur de l'utilisateur sans contact avec le serveur. Les conséquences de failles XSS basées sur DOM sont aussi variées que celles observées dans les formes les plus connues de XSS, y compris la capture du cookie, l'injection de scripts malveillants, etc, et doivent donc être traités avec la même sévérité. # Test boîte noire # Les tests boîte noire pour les vulnérabilités XSS Basées sur DOM ne sont généralement pas réalisés puisque l'accès au code source est toujours disponible, car il doit être envoyé au client pour être exécuté. # Test boîte grise # ## Test des vulnérabilités XSS DOM-Based: ## Les applications JavaScript différent sensiblement des autres types d'applications, car elles sont souvent générées dynamiquement par le serveur. Pour déterminer le type de code qui est et exécuté, le site testé doit être analysé afin de déterminer toutes les instances JavaScript en cours d'exécution et dans quelle partie l'entrée d'utilisateur est acceptée. De nombreux sites Web reposent sur de grandes bibliothèques de fonctions, qui s'étendent souvent à des centaines de milliers de lignes de code et n'ont pas été développées en interne. Dans ces cas, les tests top-down deviennent souvent la seule option réellement viable, étant donné que de nombreuses fonctions de bas niveau ne sont jamais utilisées, et que les analyser va nécessiter plus de temps que ce qui est souvent disponible. La même chose peut être dite pour les tests top-down si les entrées ou l'absence de celles-ci ne sont pas identifiées dés le départ. La saisie de l'utilisateur est disponible dans deux formes principales: * Entrée écrite sur la page par le serveur d'une manière qui ne permet pas d'XSS direct * Entrée obtenue à partir d'objets JavaScript côté client Voici deux exemples de la façon dont le serveur peut insérer des données dans JavaScript: <code>var data = “<escaped data from the server>”; var result = someFunction(“<escaped data from the server>”); </code> Et voici deux exemples d'entrées à partir d'objets JavaScript côté client: <code>var data = window.location; var result = someFunction(window.referer); </code> Bien qu'il y ait peu de différence pour le code JavaScript dans la façon dont elle est sont récupérée, il est important de noter que lorsque l'entrée est reçue par le serveur, le serveur peut appliquer toutes les permutations des données qu'il désire, alors que les permutations effectuées par des objets JavaScript sont assez bien comprises et documentées, et donc si someFunction dans l'exemple ci-dessus a une faille, alors l'exploitabilité de la premier type d'entrée dépend du filtrage effectué par le serveur, celle du second type d'entrée dépend de l'encodage fait par le navigateur de l'objet référant. Stefano Di Paulo a écrit un excellent article sur ce que les navigateurs retourne quand on leur demande pour constituer les divers éléments d'une URL de faire référence à divers attributs de documents. En outre, javascript est souvent exécuté en dehors des blocs <script>, comme en témoignent les nombreux vecteurs qui ont permis par le passé de contourner les filtres XSS. Lors de l'exploration de l'application, il est important de noter l'utilisation de scripts dans des endroits tels que les gestionnaires d'événements et les blocs CSS ayant des attributs d'expression. En outre, notez que tout CSS hors site ou objets de script devront être évalués afin de déterminer si du code peut être exécuté. L'automatisation des tests n'a qu'un succès très limité à l'identification et à la validation des vulnérabilités XSS basées sur DOM, car ça identifie généralement XSS par l'envoi d'une charge utile spécifique et tente d'observer la réponse du serveur. Cela peut bien fonctionner pour l'exemple simple ci-dessous, où le paramètre « message » est renvoyé à l'utilisateur: <code><script> var pos=document.URL.indexOf(“message=”)+5; document.write(document.URL.substring(pos,document.URL.length)); </script> </code> * mais peut ne pas être détecté dans le cas suivant : <code><script> var navAgt = navigator.userAgent; if (navAgt.indexOf(“MSIE”)!=-1) { document.write(“You are using IE as a browser and visiting site: ” + document.location.href + “.”); } else { document.write(“You are using an unknown browser.”); } </script> </code> Pour cette raison, les tests automatisés ne détecteront pas les zones qui peuvent être sensibles aux XSS basées sur DOM, à moins que l'outil de test puisse effectuer une analyse du code côté client. Des tests manuels doivent donc être entrepris, ce qui peut être fait en examinant les zones dans le code où des paramètres peuvent être utiles à un attaquant. Des exemples de telles zones comprennent les endroits où le code est écrit de façon dynamique sur la page et ailleurs, où le DOM est modifiée ou même si son exécution est exécutée directement. D'autres exemples sont décrits dans l'excellent article DOM XSS par Amit Klein, mentionnée à la fin de cette section. # Références # ## Ressources OWASP ## * dom_based_xss_prevention_cheat_sheet ## Livres blancs ## * Document Object Model (DOM) - http://en.wikipedia.org/wiki/Document_Object_Model * DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein http://www.webappsec.org/projects/articles/071105.shtml * Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources (ce qui est retourné lorsque sont demandés des choses comme document.URL, document.baseURI, location, location.href, etc )