Dans l'écosystème web moderne, le DOM (Document Object Model) joue un rôle essentiel dans la création d'expériences interactives et dynamiques pour les utilisateurs. Il s'agit d'une carte ou d'un plan qu'un navigateur Web crée lorsqu'il charge une page Web. Chaque élément que vous voyez - titres, paragraphes, boutons, images - est représenté comme un nœud dans cette structure hiérarchique. Les développeurs peuvent utiliser JavaScript pour naviguer dans cette carte, modifier des éléments, en ajouter de nouveaux ou répondre aux actions de l'utilisateur telles que les clics et les soumissions de formulaires. Par exemple, un clic sur un bouton "Show More" peut déclencher un script qui modifie le DOM pour afficher un texte caché. Le DOM étant interactif et constamment mis à jour, il sert d'interface entre le code HTML statique et le comportement dynamique que les utilisateurs expérimentent, ce qui permet d'obtenir les fonctions interactives que nous tenons pour acquises.
Cependant, cette même interactivité peut ouvrir la porte à des vulnérabilités qui sont uniquement liées au code côté client. Pour les professionnels de la sécurité - qu'il s'agisse de testeurs de pénétration ou d'ingénieurs chargés de défendre les actifs de l'entreprise - il est essentiel de comprendre les vulnérabilités des DOM, non seulement pour les exploiter, mais aussi pour les prévenir.
Le DOM dans un contexte de sécurité
Dans le cadre d'un codage sécurisé, il est essentiel de surveiller la manière dont les données circulent à l'intérieur du DOM. Une source contrôlée par un attaquant, telle qu'un paramètre d'URL (location.search), un cookie (document.cookie), ou des informations de référence (document.referrer) - peut devenir dangereux lorsqu'il est injecté dans un puits non sécurisé, tel que innerHTML ou eval(). La chaîne de la source au puits est ce qui permet les vulnérabilités basées sur le DOM.
Vulnérabilités courantes du DOM
| Type de vulnérabilité | Exemple d'évier | Description | Impact potentiel |
|---|---|---|---|
| XSS basé sur DOM | document.write()element.innerHTML | L'injection de données contrôlées par l'attaquant dans le code HTML sans vérification permet l'exécution arbitraire de JavaScript. | Vol de cookies, détournement de session, injection de contenu malveillant. |
| Redirection ouverte | emplacement.de la fenêtre | Une mauvaise gestion des URL permet aux pirates de rediriger les utilisateurs vers des sites malveillants. | Attaques par hameçonnage, diffusion de logiciels malveillants, atteinte à la confiance dans les marques. |
| Manipulation de cookies | document.cookie | L'attaquant peut écraser ou voler les cookies de session par le biais d'un code JavaScript dangereux. | Prise de contrôle de compte, détournement de session, usurpation d'identité. |
| Injection de JavaScript | eval() | Exécute la chaîne fournie par l'attaquant sous forme de code JavaScript. | Compromission complète côté client, exfiltration de données. |
| Manipulation de documents et de domaines | document.domaine | Changement de domaine pour contourner les restrictions de même origine. | Fuites de données entre domaines, escalade des privilèges. |
| Empoisonnement d'URL par WebSocket | WebSocket() | Fourniture de points d'extrémité malveillants pour les connexions WebSocket. | Interception de flux de données, actions non autorisées. |
| Manipulation de liens | élément.src | L'attaquant modifie les liens de ressources pour charger un code malveillant ou voler des données. | Injection de logiciels malveillants, traçage, pages d'atterrissage d'hameçonnage. |
| Manipulation des messages Web | postMessage() | L'envoi de messages élaborés pour manipuler la fenêtre ou le cadre cible. | Fuite de données, attaques d'origine croisée. |
| Manipulation de l'en-tête de requête Ajax | setRequestHeader() | L'attaquant contrôle les en-têtes de requête HTTP dans le code côté client. | Utilisation abusive de l'API, exploitation de type CSRF. |
| Manipulation locale du chemin d'accès aux fichiers | FileReader.readAsText() | Lecture de fichiers locaux par le biais de JS côté client sans restrictions appropriées. | Fuite de données locales sensibles. |
| Côté client Injection SQL | ExecuteSql() | Transmission de données non nettoyées aux requêtes de la base de données côté client. | Vol de données, manipulation de la base de données. |
| Manipulation de stockage HTML5 | sessionStorage.setItem() / localStorage.setItem() | Stockage de charges utiles malveillantes dans le navigateur en vue d'une exécution ultérieure. | XSS persistant, accès non autorisé aux données du client. |
| Injection XPath côté client | document.evaluate() | L'injection dans les requêtes XPath peut permettre à un attaquant d'accéder aux données XML. | Fuites de données, manipulation des Logique d'application basée sur XML. |
| Injection JSON côté client | JSON.parse() | L'analyse de JSON altéré provenant de sources non fiables permet l'injection d'objets arbitraires. | Ecrasement de données, manipulation logique. |
| Manipulation des données DOM | element.setAttribute() | La définition d'attributs avec des données non fiables peut déclencher des comportements malveillants. | XSS, clickjacking, logic bypass. |
| Déni de service (DoS) | RegExp() | Les modèles de regex importants ou malveillants bloquent le navigateur. | Temps d'arrêt de l'application, dégradation des performances. |
Comment les vulnérabilités des DOM sont-elles détectées ?
Les équipes de sécurité utilisent généralement une combinaison de stratégies.
- Balayage actifL'utilisation d'outils tels que Burp Suite ou OWASP ZAP permet aux testeurs de simuler et d'observer des interactions non sûres avec le DOM.
- Découverte passive consiste à parcourir des ressources telles que Shodan, ZoomEye et PublicWWW, ou même des instantanés historiques dans la Wayback Machine, afin de découvrir des données sensibles cachées dans la couche DOM.
- Analyse automatisée des expressions rationnelles et de l'intelligence artificielle, associe le filtrage des informations d'identification connues à une analyse pilotée par l'IA qui cartographie les flux Source → Sink, réduisant ainsi considérablement le délai entre la détection et la remédiation.
Se défendre contre les vulnérabilités du DOM
Les défenses solides commencent par une validation disciplinée des entrées - idéalement par le biais d'une liste blanche - afin de garantir que seules les données fiables atteignent le DOM.
Les stratégies de codage doivent être adaptées au contexte : codage HTML pour la sortie des pages, échappement JavaScript pour les points d'injection de scripts et codage URL pour la construction de liens.
Les clés d'API, lorsqu'elles doivent absolument apparaître dans le code frontal, doivent être verrouillées à l'aide de contrôles des référents et de l'origine, de restrictions d'IP et de limites de taux.
Les équipes devraient procéder à un examen du DOM juste avant le déploiement, en supprimant les secrets et le code dangereux, et en révoquant toutes les informations d'identification qui ont été exposées, même dans les instantanés archivés.
Renforcer la sécurité des DOM avec Penligent
Traditionnellement, la réalisation d'un audit approfondi de la sécurité des DOM nécessitait l'utilisation de nombreux outils - Nmap pour la découverte, Burp Suite pour les tests d'injection, SQLmap pour l'exploitation - et l'examen manuel de chaque constatation pour en vérifier l'exactitude.
Penligent change la donne en permettant aux testeurs de décrire leur objectif en langage clair. Une demande telle que "analyser ce site web pour détecter les vulnérabilités DOM" déclenche un flux de travail intelligent : l'IA intègre plus de deux cents outils de sécurité, dont Nmap, Burp Suite, SQLmapetc., pour effectuer des analyses ciblées sur les chaînes potentielles Source → Sink, valider chaque résultat pour éliminer les faux positifs et les classer par ordre de gravité. Pour les experts en sécurité chevronnés comme pour les nouveaux venus, cela transforme les audits DOM de marathons manuels de plusieurs jours en processus rationalisés et très précis, réalisés en quelques heures, voire en quelques minutes.
