XSS basé sur le DOM

Qu'est-ce que le XSS basé sur le DOM#

Le XSS basé sur le DOM (CWE-79, Type-0 XSS dans la taxonomie OWASP) est une variante où la vulnérabilité existe entièrement dans le JavaScript côté client. La réponse du serveur est légitime — aucune donnée malveillante ne passe par la couche HTTP. À la place, le code côté client lit des données contrôlées par l'attaquant depuis une source DOM et les écrit dans un sink dangereux sans sanitization. Le script s'exécute dans le navigateur de la victime sous l'origine de l'application.

Cela rend le XSS DOM fondamentalement différent des variantes réfléchie et stockée : les WAF côté serveur ne voient aucun trafic d'attaque, et tout outil DAST qui examine uniquement les réponses HTTP ne le détectera pas. La détection nécessite une analyse JavaScript dynamique — un navigateur sans tête instrumentant l'exécution réelle, traçant les données de la source au sink.

Sources et sinks#

Le flux de données source → sink est le modèle central de l'analyse du XSS DOM.

Sources — entrées contrôlables par l'attaquant que JavaScript peut lire :

Sinks — opérations d'écriture DOM dangereuses pouvant produire une exécution de script :

Mécanisme#

Le schéma classique de XSS DOM lit depuis location.search et écrit dans innerHTML :

// VULNÉRABLE — de la source au sink sans sanitization
const params = new URLSearchParams(location.search);
const name = params.get('name');
document.getElementById('greeting').innerHTML = 'Bonjour, ' + name;
 
// Payload : ?name=<img src=x onerror=alert(document.domain)>
// Le navigateur insère le HTML brut, exécute le gestionnaire onerror

Le serveur renvoie une réponse 200 normale. Toute la vulnérabilité existe dans deux lignes de JavaScript côté client.

Variante postMessage — exploitable depuis n'importe quelle page cross-origin :

// VULNÉRABLE — pas de validation d'origine
window.addEventListener('message', function(e) {
  // e.origin non vérifié — n'importe quelle origine peut envoyer
  document.getElementById('content').innerHTML = e.data; // sink
});

// Page de l'attaquant (n'importe quelle origine) :
const target = window.open('https://victim.com/app');
setTimeout(() => {
  target.postMessage('<img src=x onerror=alert(document.domain)>', '*');
}, 1000);

CVE-2024-49038 (Microsoft Copilot Studio, CVSS 9.3) a exploité un schéma postMessage/injection DOM dans un service AI cloud, permettant une escalade de privilèges cross-tenant.

Techniques avancées#

Prototype pollution → XSS#

La prototype pollution définit des propriétés arbitraires sur Object.prototype via des paramètres de requête craftés. Quand le code de l'application ou une bibliothèque lit une propriété indéfinie d'un objet quelconque, elle remonte au prototype pollué.

// Étape 1 : Prototype pollution via URL
// ?__proto__[transport_url]=data:,alert(document.domain);
// Définit : Object.prototype.transport_url = "data:,alert(1)"
 
// Étape 2 : Le gadget jQuery lit la propriété
$.ajax({ url: '/api', jsonp: callback });
// jQuery lit en interne options.transport_url — indéfini sur l'objet options
// Remonte vers Object.prototype.transport_url → le payload de l'attaquant s'exécute

CVE-2026-41238 démontre que DOMPurify lui-même est un gadget de prototype pollution : polluer Object.prototype.tagNameCheck avec une regex permissive amène DOMPurify à laisser passer des éléments arbitraires dans la sanitization, convertissant une vulnérabilité de prototype pollution n'importe où dans l'application en bypass XSS complet.

Outils de détection : Burp Suite DOM Invader (scanner de prototype pollution intégré), l'extension Chrome PPScan, et le dépôt GitHub client-side-prototype-pollution (liste de gadgets maintenue par BlackFan).

DOM clobbering#

Le DOM clobbering utilise des éléments HTML nommés — injectés via injection HTML dans des contextes où <script> est bloqué — pour masquer des variables JavaScript globales.

<!-- Clobber à un niveau : window.x devient un HTMLElement -->
<a id="x" href="https://attacker.com/malicious.js"></a>
 
<!-- Clobber à deux niveaux : window.config.cdn devient une chaîne via l'attribut href d'une ancre -->
<a id="config"><a id="config" name="cdn" href="https://attacker.com">

Quand le code de l'application exécute var url = window.config.cdn || '/assets/', la valeur clobbered config.cdn est https://attacker.com — contrôlée par l'attaquant.

CVE-2024-7524 — Contournement CSP strict-dynamic de Firefox : Le shim ETP du SDK Facebook lit document.currentScript.src sans valider le tagName. Injecter <img name="currentScript" src="data:,alert(document.domain)"> amène le shim à charger l'URI data: comme script enfant de confiance sous strict-dynamic, contournant entièrement le CSP.

CVE-2024-4367 — Sink new Function() dans PDF.js#

new Function() est dangereux précisément parce qu'il contourne entièrement l'étape de parsing HTML — aucune injection de balise nécessaire — ce qui le rend invisible aux scanners qui n'accrochent que innerHTML ou document.write. Le chemin rapide de rendu de polices de PDF.js utilisait exactement ce sink pour compiler le tableau FontMatrix d'un PDF en JavaScript exécutable, permettant à une définition de police malveillante d'exécuter du code arbitraire dès l'ouverture du fichier par la victime.

CVE-2024-4367 : deep-dive XSS DOM dans PDF.js#

CVE-2024-4367 (publié le 14 mai 2024 sur NVD ; avis Mozilla MFSA-2024-21, MFSA-2024-22, MFSA-2024-23) est un XSS basé sur le DOM dans PDF.js, le moteur de rendu PDF en JavaScript de Mozilla, intégré à Firefox et distribué en standalone via le package npm pdfjs-dist (~2,7 millions de téléchargements hebdomadaires au moment de la divulgation). Il obtient un score CVSS 3.1 de 8,8 ÉLEVÉ (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) et est classé CWE-754 (vérification incorrecte d'une condition inhabituelle ou exceptionnelle) — une absence de vérification de type, pas un bug classique d'échappement de chaîne.

Vecteur d'attaque#

PDF.js précompile les instructions de rendu de glyphes en JavaScript pour la performance dès que son option isEvalSupported est activée — c'était le comportement par défaut à l'époque. Le compilateur construit un corps new Function() à partir du tableau FontMatrix de la police, six valeurs que la spécification PDF définit comme des nombres. PartialEvaluator.translateFont() lit ce tableau directement depuis le dictionnaire de police du PDF et le joint dans le code source de la fonction sans vérifier que chaque entrée est bien un nombre.

Comme le format PDF autorise techniquement qu'une entrée FontMatrix soit une chaîne PDF, un attaquant en glisse une :

/FontMatrix [1 2 3 4 5 (0\); alert\('CVE-2024-4367'\))]

La chaîne finale referme la liste d'arguments numériques légitime et ajoute du JavaScript arbitraire, que PDF.js compile ensuite tel quel dans le corps de la Function.

Mécanisme#

1. La victime ouvre ou prévisualise un PDF contenant le FontMatrix malveillant.
2. PartialEvaluator.translateFont() extrait le tableau pendant le parsing de la police — aucune vérification de type sur les entrées individuelles.
3. Le chemin rapide de compilation des glyphes joint le tableau dans une chaîne source new Function(...) et l'invoque — le même schéma de sink Function(chaîne)() que dans le tableau ci-dessus, atteint via les métadonnées de police plutôt qu'une URL.
4. Le code injecté s'exécute dans l'origine propre du visualiseur PDF (resource://pdf.js dans Firefox, ou l'origine de la page hôte pour pdfjs-dist embarqué), avec accès à window.PDFViewerApplication.url et à tout autre objet accessible depuis cette origine.

Aucune balise <script> ni étape de parsing HTML n'est impliquée — toute la chaîne vit à l'intérieur d'un appel au constructeur JavaScript Function, ce qui explique pourquoi elle a échappé aux sanitizers PDF et aux scanners XSS DOM centrés sur le HTML.

Impact et versions affectées#

L'exploitation nécessite que la victime ouvre un PDF malveillant (UI:R) mais aucune authentification ni interaction préalable avec le site cible — toute application rendant des PDF non fiables côté client avec une version vulnérable de pdfjs-dist héritait d'une exécution JavaScript complète dans sa propre origine.

Remédiation#

• Mettre à jour pdfjs-dist vers >= 4.2.67 ; Firefox vers >= 126 ; Firefox ESR vers >= 115.11 ; Thunderbird vers >= 115.11. Le correctif supprime le chemin de compilation Function() non validé.
• Atténuation immédiate sans mise à jour — désactiver le chemin rapide :

// Options du visualiseur PDF.js — désactive le chemin rapide de compilation de glyphes vulnérable
const loadingTask = pdfjsLib.getDocument({
  url: pdfUrl,
  isEvalSupported: false,
});

• Défense en profondeur — une CSP sans unsafe-eval dans script-src bloque directement le constructeur Function, fermant toute cette classe de sink même contre des variantes non encore découvertes. C'est le même contrôle qui protège contre les techniques de contournement de sanitizer couvertes dans mXSS — Mutation XSS.

CVE-2024-4367 est l'un des incidents à l'origine du basculement plus large vers la surface d'attaque basée sur le DOM — voir la recherche XSS Trends 2025–2026 de BreachVex pour l'état actuel du paysage.

Détection#

Tests manuels#

1. Identifier les sources DOM : Examiner le JavaScript pour les appels à location.search, location.hash, document.referrer, window.name, addEventListener('message', ...)
2. Tracer le flux de données : Suivre la variable depuis la source à travers tout traitement jusqu'à une assignation de sink
3. Injecter dans la source : Placer le payload dans le hash ou la requête URL, observer le comportement du navigateur
4. Tester postMessage : Ouvrir la cible dans une popup, envoyer postMessage avec un payload XSS depuis une origine contrôlée par l'attaquant

// Test manuel rapide — coller dans la console du navigateur
// Vérifie si location.hash atteint innerHTML
const hash = decodeURIComponent(location.hash.slice(1));
// Vérifier toutes les assignations innerHTML manuellement dans l'onglet Sources des DevTools

Détection automatisée#

• Burp Suite DOM Invader — la référence ; instrumente le moteur JavaScript de Chrome pour accrocher tous les sinks, tracer le flux de données source → sink et générer automatiquement des payloads PoC adaptés au contexte
• CodeQL — analyse sémantique modélisant le flux de données complet de la source au sink à travers fichiers et modules ; précision plus élevée que les approches par correspondance de chaînes
• Semgrep mode taint — plus rapide, précision moindre ; adapté à l'intégration en pipeline CI

BreachVex détecte le XSS DOM en utilisant des sessions de navigateur sans tête instrumentées qui accrochent tous les sinks dangereux au chargement de la page, tracent l'arrivée du canary à chaque sink avec des traces de pile complètes, et confirment l'exécution en interceptant la boîte de dialogue résultante.

Prévention#

API Trusted Types (Élimination au niveau de la plateforme)#

Les Trusted Types (appliquées sur YouTube, Microsoft 365 et Stripe) empêchent les sinks DOM d'accepter des chaînes brutes :

// En-tête CSP pour appliquer :
// Content-Security-Policy: require-trusted-types-for 'script'
 
// Politique sûre — DOMPurify sanitise avant assignation
const policy = trustedTypes.createPolicy('default', {
  createHTML: (input) => DOMPurify.sanitize(input),
});
 
element.innerHTML = policy.createHTML(userInput); // OK — passe par le sanitizer
element.innerHTML = userInput;                    // TypeError en mode d'application

Cela prévient le XSS DOM même quand un flux source-vers-sink existe — le navigateur lance une exception avant que le sink s'exécute.

Alternatives de sinks sûrs#

Remplacer les sinks dangereux par des équivalents sûrs :

// VULNÉRABLE : innerHTML avec données utilisateur
element.innerHTML = userInput;
 
// SÛR : textContent pour le texte brut (ne rend jamais le HTML)
element.textContent = userInput;
 
// SÛR : construction DOM structurée (pas de parsing HTML)
const p = document.createElement('p');
p.textContent = userInput;
container.appendChild(p);
 
// SÛR : DOMPurify + Trusted Types quand le HTML est nécessaire
element.innerHTML = trustedTypesPolicy.createHTML(DOMPurify.sanitize(userInput));

Validation de l'origine postMessage#

// VULNÉRABLE — pas de vérification d'origine
window.addEventListener('message', function(e) {
  element.innerHTML = e.data;
});
 
// SÛR — liste d'autorisation stricte d'origines attendues
const ALLOWED_ORIGINS = new Set(['https://app.example.com', 'https://checkout.example.com']);
 
window.addEventListener('message', function(e) {
  if (!ALLOWED_ORIGINS.has(e.origin)) return; // rejeter les origines inconnues
  element.textContent = e.data;               // utiliser un sink sûr
});

Atténuation de la prototype pollution#

// Geler Object.prototype pour empêcher la pollution
Object.freeze(Object.prototype);
 
// Ou : utiliser Object.create(null) pour les objets de configuration (pas de chaîne prototype)
const config = Object.create(null);
config.timeout = 5000;
// La pollution de Object.prototype ne peut pas atteindre les propriétés de config

Ressources#

• XSS — Vue d'ensemble pilier
• OWASP DOM-based XSS Prevention Cheat Sheet
• PortSwigger : XSS basé sur le DOM — Labs
• Trusted Types MDN