XSS basée sur le DOM : quand tout se passe côté client

Une faille sans aucun aller-retour serveur

Les deux chapitres précédents impliquaient tous les deux un serveur : soit pour refléter une valeur reçue, soit pour la stocker et la resservir. Une XSS basée sur le DOM n’a besoin ni de l’un ni de l’autre : la faille vit entièrement dans le JavaScript qui tourne déjà dans le navigateur.

Le vocabulaire : source et sink

Deux notions suffisent à décrire n’importe quelle XSS DOM-based :

• Une source : l’endroit d’où vient une donnée que le site ne contrôle pas (location.hash, un champ de saisie, document.referrer, un message reçu via postMessage).
• Un sink : l’endroit où cette donnée est écrite d’une façon qui peut être interprétée comme du code actif (innerHTML, document.write, eval).

const valeur = champDeSaisie.value;   // source : donnee non fiable
element.innerHTML = valeur;            // sink : ecriture dangereuse

Dès qu’une donnée voyage d’une source vers un sink sans passer par un traitement qui neutralise le HTML actif, la faille existe, indépendamment de tout serveur.

La démonstration : tape, regarde s’exécuter

Contrairement aux démonstrations précédentes, celle-ci est directement pilotée par ce que tu tapes. Le champ ci-dessous écrit sa valeur dans la page en temps réel, via innerHTML :

<!-- HTML -->
<input type="text" id="champ" placeholder="Tape ici..." style="width:100%;box-sizing:border-box;padding:6px;" />
<div id="resultat" style="margin-top:10px;"></div>

// JS
document.getElementById('champ').addEventListener('input', function (e) {
// Sink dangereux : le texte tape est ecrit directement dans le DOM
document.getElementById('resultat').innerHTML = e.target.value;
});

Tape <img src=x onerror="console.log('XSS DOM executee')"> dans le champ : le message apparaît dans la console dès que tu termines de taper la balise, sans rechargement de page, sans aucun serveur impliqué.