Articles

Script Intersite basé sur DOM

Posted on

La technique XSS moins connue

  • DOM signifie Document Object Model
  • XSS signifie cross-site scripting
  • La principale différence entre les vulnérabilités XSS basées sur DOM et les autres vulnérabilités XSS est que la charge utile est intégrée côté client plutôt que côté serveur
  • Les vulnérabilités XSS basées sur DOM doivent donc être évitées côté client

Vulnérabilités XSS (Cross-site scripting) d’abord est devenu connu grâce à l’Avis CERT CA-2000-02 (Balises HTML malveillantes Intégrées dans les Requêtes Web des Clients), bien que ces vulnérabilités aient été exploitées auparavant. Donc, XSS existe déjà depuis un moment. Et comme on pouvait s’y attendre, il y a déjà eu un certain nombre d’articles de Labs sur le sujet, y compris Cross Site Scripting – Le Danger sous-estimé et Cross-Site–Scripting et La Prévention de l’injection de script – Un Bref Guide. Cependant, cet article se concentre en grande partie sur les scripts inter-sites basés sur DOM, un terme inventé pour la première fois en 2005 par Amit Klein. Il a rendu publique la définition du script intersite basé sur DOM (XSS) et l’a délimitée des autres vulnérabilités de script intersite. Pour comprendre les scripts inter-sites basés sur DOM, vous avez d’abord besoin d’une compréhension plus approfondie du DOM.

Qu’est-ce que le DOM ?

Le modèle d’objet Document est une interface de programme qui définit la structure des documents. Ce qui est pertinent pour nos objectifs, c’est que DOM fournit la représentation orientée objet des documents HTML, en particulier:

  • Comment un élément HTML est représenté en tant qu’objet
  • Quels sont les attributs d’un élément HTML
  • Quelles méthodes peuvent être utilisées pour accéder à un élément HTML
  • Quels sont les événements d’un élément HTML

Cela signifie que DOM spécifie comment les éléments HTML peuvent être trouvés, ajoutés, modifiés ou supprimés dans le navigateur . Cela signifie que DOM offre la possibilité de manipuler des pages HTML. De nos jours, JavaScript est généralement utilisé pour ce genre de manipulation.

Il convient de noter que chaque navigateur implémente la norme DOM différemment. Cela peut affecter si une attaque XSS DOM spécifique fonctionne dans un navigateur particulier.

Qu’est-ce que le XSS basé sur DOM ?

Une vulnérabilité XSS basée sur le DOM survient lorsque le DOM est utilisé pour générer du contenu dynamique contenant des entrées utilisateur qui peuvent être traitées sans vérification. Ce type d’attaque est effectué avec JavaScript dans le navigateur de l’utilisateur. Ici, les emplacements que les entrées d’utilisateur (malveillantes) apportent dans le DOM sont désignés comme source. Les emplacements dans lesquels une entrée utilisateur (malveillante) peut être exécutée dans le DOM sont désignés comme sink.

Un exemple de vulnérabilité de script intersite simple:

<!DOCTYPE html><html> <body> <script> var source = "Hello " + decodeURIComponent(location.hash.split("#")); //Source var divElement = document.createElement("div"); divElement.innerHTML = source; //Sink document.body.appendChild(divElement); </script> </body></html>

La vulnérabilité peut, par exemple, être déclenchée avec la requête GET suivante:

GET www.vulnerable-website.example#<img src="test" onerror="alert('XSS')">

Nous pouvons voir que cet exemple nécessitait l’utilisation de la méthode decodeURIComponent. En effet, les navigateurs modernes encodent des caractères spéciaux dans l’URL et l’attaque ne fonctionnerait pas sans que ces caractères spéciaux soient décodés. Le contenu de la variable source est ajouté à l’élément div en utilisant innerHTML. C’est l’élément problématique dans le code, car son affectation à innerHTML entraîne l’interprétation de la valeur incluse dans celui-ci en HTML. Si la valeur contient JavaScript, elle est également exécutée.

Il convient de noter que cela ne modifie pas la réponse du serveur. La modification malveillante ne survient que lorsque le code JavaScript est exécuté côté client, ce que le DOM modifie par la suite.

Les sources et puits les plus connus sont énumérés ci-dessous. Il convient de noter qu’il ne s’agit en aucun cas d’une liste exhaustive.

Sources

  • document.URL
  • document.référent
  • emplacement
  • emplacement.href
  • emplacement.recherche
  • emplacement.hash
  • emplacement.chemin

Éviers

  • eval
  • setTimeout
  • setInterval
  • document.écrivez l’élément
  • .innerHTML

Empêcher le XSS basé sur DOM

Parce qu’il y a des cas où la charge utile n’arrive jamais au serveur, empêcher cette vulnérabilité n’est pas une tâche du côté serveur. L’exemple ci-dessus est l’un de ces cas. La raison en est que le contenu qui apparaît après un caractère # n’est pas envoyé par le navigateur au serveur.

La première et la plus importante recommandation est d’éviter d’utiliser des données contrôlées par l’utilisateur pour la génération dynamique de contenu dans la mesure du possible. Si cela est totalement inévitable, la meilleure façon d’empêcher les XSS basés sur DOM est d’utiliser des méthodes de sortie sécurisées (sink) qui empêchent l’exécution de tout code malicieusement intégré. Dans l’extrait de code ci-dessus, la seule façon de sécuriser le code est de remplacer .innerHTML par .textContent. En effet, contrairement à textContent ne sont pas exécutés.

La feuille de triche de prévention XSS basée sur DOM d’OWASP contient de nombreux conseils utiles pour développer des sites Web dynamiques sécurisés avec JavaScript. Vous y trouverez également des descriptions de l’encodage dépendant du contexte, qui est requis chaque fois qu’il est impossible de passer à une méthode de sortie sécurisée.

Différences par rapport aux autres vulnérabilités XSS

La différence la plus importante est l’endroit où l’attaque est intégrée dans le code. Contrairement à d’autres vulnérabilités de script intersite, le code n’est pas intégré côté serveur, mais plutôt côté client. Cela signifie que la charge utile ne peut pas être trouvée dans le code de réponse. Les vulnérabilités XSS basées sur le DOM ne peuvent donc être détectées qu’au moment de l’exécution ou en vérifiant le DOM du site Web.

Dans la plupart des cas, il n’est pas facile de trouver des vulnérabilités XSS basées sur DOM. Une approche utile qui utilise l’approche d’analyse de code statique est décrite dans l’article Burp based-xss.

À propos de l’auteur

 Andrea Hauser

Andrea Hauser est diplômée d’un Bachelor of Science FHO en technologies de l’information à l’Université des Sciences Appliquées de Rapperswil. Elle concentre son travail offensif sur les tests de sécurité des applications web et la réalisation de campagnes d’ingénierie sociale. Son objectif de recherche est la création et l’analyse de deepfakes. (ORCID 0000-0002-5161-8658)

Liens

  • http://www.webappsec.org/projects/articles/071105.html
  • https://support.portswigger.net/customer/portal/articles/2325926-using-burp-scanner-to-test-for-dom
  • https://www.cert.org/historical/advisories/CA-2000-02.cfm
  • https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
  • https://www.w3.org/DOM/

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.