Qu’est-ce que le cross-site scripting basé sur DOM ?

Le script intersite basé sur DOM est un type de script intersite (XSS) dans lequel l’attaque tire parti du modèle d’objet de document (DOM).

Comment fonctionne le cross-site scripting basé sur DOM ?

Le DOM est une structure de données interne qui stocke tous les objets et propriétés d’une page Web. Par exemple, chaque balise utilisée dans le code HTML représente un objet DOM. De plus, le DOM d’une page Web contient des informations sur des propriétés telles que l’URL de la page et les méta-informations. Les développeurs peuvent faire référence à ces objets et propriétés à l’aide de JavaScript et les modifier de manière dynamique.

Le modèle d’objet de document est ce qui rend possibles les applications dynamiques d’une seule page. Cependant, c’est aussi ce qui rend possible les scripts intersites basés sur DOM.

Contrairement à tous les autres types de scripts intersites, XSS basé sur DOM est une vulnérabilité purement côté client. Cela signifie que lors d’une attaque XSS basée sur DOM, la charge utile n’atteint jamais le serveur. Toute l’attaque se produit dans le navigateur Web.

Le XSS basé sur DOM est similaire au XSS réfléchi car aucune information n’est stockée pendant l’attaque. Une attaque XSS basée sur DOM est également menée en incitant une victime à cliquer sur une URL malveillante.

Sources et puits dans les scripts intersites basés sur DOM

Chaque vulnérabilité XSS basée sur DOM comporte deux éléments : la source de l’entrée utilisateur et la cible où cette entrée utilisateur est écrite, appelée récepteur. Les sources populaires que les attaquants peuvent manipuler sont document.URL, document.documentURI, location.href, location.search, location.*, window.nameet document.referrer. Les puits populaires sont document.write, (element).innerHTML, eval, setTimeout, setIntervalet execScript. Notez que cette liste n’est pas exhaustive et que de nombreuses autres sources et puits existent également.

Pour que le code JavaScript soit vulnérable au XSS basé sur DOM, il doit prendre des informations d’une source qui peut être contrôlée par l’attaquant, puis transmettre ces informations à un récepteur.

Exemple de script intersite basé sur DOM

Dans cet exemple, le développeur souhaite afficher le nom de l’utilisateur sur la page du tableau de bord ( dashboard.html ). Le nom de l’utilisateur est passé à l’application en tant que paramètre dans l’URL :

<html>
(...)
Dashboard for
<script>
   var pos=document.URL.indexOf("context=")+8;
   document.write(decodeURIComponent(document.URL.substring(pos)));
</script>
(...)
</html>
 

Le script en ligne recherche context=dans l’URL ( document.URL.indexOf("context=")), prend tout le texte à sa droite ( +8signifie 8 caractères à droite du début de context=) et utilise document.writepour insérer ce texte directement dans HTML pour qu’il soit interprété par le navigateur.

Si vous appelez l’URL suivante :

http://www.example.com/dashboard.html?context=Thomas

la page dira :

Dashboard for Thomas

L’attaque de script intersite basée sur DOM

L’attaquant crée l’URL suivante :

http://www.example.com/dashboard.html?context=
%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%4c%45
%41%56%45%20%54%48%49%53%20%50%41%47%45%21%20%59%4f
%55%20%41%52%45%20%42%45%49%4e%47%20%48%41%43%4b%45
%44%21%22%29%3b%3c%2f%73%63%72%69%70%74%3e

La longue chaîne de codes hexadécimaux dans cette charge utile est une forme encodée en URL du contenu suivant :

<script>alert("LEAVE THIS PAGE! YOU ARE BEING HACKED!");</script>
 

Ensuite, l’attaquant envoie l’URL à la victime, par exemple, dans un e-mail ou un message instantané. La victime clique sur l’URL, ce qui oblige son navigateur à ouvrir la page dashboard.html et à exécuter le script malveillant. Cela réécrit le contenu du document et insère la balise suivante dans le code HTML interprété par le navigateur :

Dashboard for <script>alert("LEAVE THIS PAGE! YOU ARE BEING HACKED!");</script>
 

En conséquence, le navigateur affiche une fenêtre pop-up invitant l’utilisateur à quitter la page. Les conséquences sont que les utilisateurs ciblés cesseront de visiter l’application Web, craignant pour leur sécurité.

Le correctif

Informé de la vulnérabilité, le développeur réécrit le code à l’aide d’un puits sécurisé. Par conséquent, le contenu non fiable de la source sera toujours interprété comme du texte et non comme du code :

<html>
(...)
Dashboard for <span id="contentholder"></span>
<script>
   var pos=document.URL.indexOf("context=")+8;
   document.getElementById("contentholder").textContent = 
       document.URL.substring(pos,document.URL.length);
</script>
(...)
</html>
 

Le développeur crée un objet d’espace réservé et écrit le nom de l’utilisateur non pas directement en HTML, mais dans la textContentpropriété de l’objet d’espace réservé (à l’aide d’un récepteur sécurisé). Cela garantit que le navigateur n’interprétera pas ce contenu comme du code et l’affichera simplement comme du texte.

Conséquences des attaques de script intersite basées sur DOM

Les vulnérabilités de script intersite basées sur DOM ne sont pas très courantes, mais les conséquences d’une attaque réussie peuvent être aussi graves que celles d’autres attaques XSS réfléchies . Voici quelques actions qu’un hacker black-hat pourrait effectuer sur la base de l’exemple simple présenté précédemment :

  • Ils pourraient créer une campagne de phishing et envoyer des millions d’e-mails contenant un lien malveillant avec une charge utile qui redirige les utilisateurs vers une page de phishing conçue pour imiter votre application Web. En conséquence, des millions d’utilisateurs pourraient potentiellement se faire voler leurs informations d’identification et blâmer votre application Web, ce qui nuirait gravement à votre réputation.
  • Ils pourraient créer une charge utile qui envoie l’utilisateur vers une page malveillante qui imite la page de connexion de votre application. Ensuite, ils pourraient envoyer cette URL malveillante à vos utilisateurs internes, même votre PDG. Si même l’un de vos utilisateurs tombe dans le piège, l’attaquant obtiendra ses informations d’identification pour intensifier l’attaque. En fin de compte, cela pourrait permettre à des acteurs malveillants d’accéder à d’autres systèmes informatiques de votre organisation.

Comment détecter les vulnérabilités de script intersite basées sur DOM

En raison de la nature unique des vulnérabilités XSS basées sur DOM, de nombreux outils de sécurité des applications Web ne parviennent pas à les détecter. C’est le cas des outils qui se concentrent sur le code côté serveur et l’analyse des requêtes HTTP mais sont incapables d’analyser les scripts exécutés dans le navigateur. Par exemple, la plupart des outils SAST et IAST sont conçus pour analyser des langages spécifiques côté serveur et ignorer le code JavaScript. Par conséquent, pour couvrir les menaces liées au XSS basé sur DOM, vous avez besoin de tests de pénétration manuels ou de scanners DAST (ou IAST dynamiques) professionnels qui utilisent un moteur de navigateur intégré pour tester le XSS basé sur DOM.

Comment prévenir les vulnérabilités de script intersite basées sur DOM

La meilleure façon d’éviter complètement les vulnérabilités XSS basées sur DOM dans votre code JavaScript est d’utiliser la méthode de sortie correcte (un récepteur sûr). Par exemple, si vous voulez écrire dans un <div>élément, n’utilisez pas innerHtml. Utilisez plutôt innerTextou textContent.

Notez que tous les éléments DOM n’ont pas de méthode de sortie sûre. Il y a des cas où vous devez simplement éviter d’utiliser des données non fiables. Par exemple, vous ne devez jamais écrire de données non fiables dans des récepteurs tels que evalou execScript.

Vous pouvez également utiliser des techniques de protection XSS typiques (filtrage et échappement) appliquées à JavaScript. Malheureusement, contrairement aux langages côté serveur, il n’existe pas de bibliothèques JavaScript universelles pour vous aider à filtrer et à échapper les données. Les développeurs doivent donc écrire et gérer eux-mêmes ces fonctionnalités. Pour XSS basé sur DOM, le filtrage et l’échappement appropriés sont un problème complexe, décrit en détail dans une feuille OWASP dédiée .

Comment atténuer les vulnérabilités de script intersite basées sur DOM

Contrairement à d’autres vulnérabilités de script intersite, vous ne pouvez pas atténuer XSS basé sur DOM à l’aide d’un pare-feu d’application Web (WAF) ou d’une protection de cadre générique comme la validation de demande dans ASP.NET. De tels mécanismes sont totalement inutiles contre les attaques XSS basées sur DOM car la charge utile n’atteint jamais le serveur.

Il n’y a aucun moyen d’atténuer ou d’empêcher temporairement les attaques XSS basées sur DOM de type zero-day autrement que de prêter attention au code de vos applications Web, d’analyser toutes vos applications aussi souvent que possible et de maintenir à jour vos applications tierces.

Le cross-site scripting basé sur DOM est un type d’attaque de cross-site scripting (XSS) exécuté dans le Document Object Model (DOM) d’une page chargée dans le navigateur. Une attaque XSS basée sur DOM est possible si l’application Web écrit des données sur le DOM sans nettoyage approprié.

XSS basé sur DOM n’est possible que dans des cas spécifiques, mais il est considéré comme particulièrement dangereux car il est difficile à détecter et à atténuer. Étant donné que XSS basé sur DOM n’implique pas le côté serveur de l’application, les pare-feu d’applications Web ne peuvent pas du tout s’en protéger. Il n’existe donc aucun moyen simple d’éviter les attaques DOM XSS de type zero-day.

Pour empêcher DOM XSS, vous pouvez utiliser des techniques de protection XSS générales : filtrage et échappement, mais il n’existe pas de bibliothèques JavaScript universelles pour vous aider à filtrer et à échapper les données. Les développeurs doivent donc écrire et gérer eux-mêmes ces fonctionnalités.

{"cpt":"service","style":"9","columns":"3","show":"6","order":"DESC","orderby":"DESC"}

Nos Services en Cybersécurité

Protégez-vous maintenant !

Forfait Évaluation de la surface d’attaque

La cible de cette évaluation de la surface d’attaque est les ressources réseau, les systèmes et les terminaux. Il n’y a pas de ciblage des membres ou des employés des organisations à des fins d’ingénierie sociale.

Forfait Évaluation de la vulnérabilité

Nous sommes en mesure de fournir des évaluations de vulnérabilité des applications web , des serveurs connectés à Internet et des gammes de réseaux connectés à Internet .

Analyse de vulnérabilité

Cycuri propose des analyses de vulnérabilité ponctuelles ou régulières de votre périmètre externe, de vos applications Web ou de votre réseau interne.

Forfait Évaluation WordPress

Nos services d’évaluation WordPress professionnelle sont populaires auprès de tous ceux qui souhaitent un examen par un tiers indépendant de leur posture de sécurité.

Test d’intrusion d’application Web

Que votre application Web soit destinée aux employés, B2B ou B2C, il existe un niveau de confiance inhérent qui est supposé lorsque les utilisateurs sont autorisés à entrer, naviguer et utiliser des applications et/ou des portails d’applications.

Test d’intrusion Black-Box externe

Un test d’intrusion externe Black-Box imite les actions d’un adversaire réel en tentant d’exploiter les faiblesses de la sécurité du réseau sans les dangers d’une menace réelle.

Script intersite basé sur DOM