Le XSS basé sur le DOM se produit lorsque des scripts malveillants sont exécutés via du JavaScript côté client qui modifie le DOM de manière non sécurisée. Contrairement au XSS traditionnel, ces attaques n'ont pas besoin d'interagir avec le serveur. Elles exploitent généralement le code JavaScript vulnérable qui traite les données provenant de sources non sécurisées telles que les paramètres URL. La prévention nécessite une gestion minutieuse des entrées utilisateur dans le code côté client et un encodage correct des sorties.
Le cross-site scripting basé sur le DOM est une faille côté client où la vulnérabilité réside entièrement dans le JavaScript de la page plutôt que dans la réponse du serveur. La page lit une donnée depuis une source que l'attaquant peut influencer, le plus souvent le fragment d'URL (location.hash), la chaîne de requête, document.referrer ou le stockage web, et la transmet à un sink dangereux tel que innerHTML, la méthode document write ou eval sans l'assainir. Le navigateur interprète alors la donnée de l'attaquant comme du balisage ou du code et l'exécute. Comme la valeur corrompue peut ne jamais quitter le navigateur, la charge utile peut se trouver après le dièse dans une URL, que les serveurs ne reçoivent pas, si bien que le serveur ne voit jamais l'attaque et ne peut ni la journaliser ni la filtrer.
Le XSS DOM confère les mêmes pouvoirs au sein de l'origine que les autres XSS : lire les jetons et les données de la page, forger des requêtes et réécrire l'interface, le tout sous l'origine de confiance du site. Il est facile à manquer car les défenses côté serveur, les pare-feux applicatifs web et la journalisation des requêtes ne s'appliquent pas aux données qui restent dans le navigateur ou se cachent dans le fragment d'URL. Les applications monopages modernes y sont particulièrement exposées, puisque le routage, la génération de modèles et le rendu se font tous côté client et puisent abondamment dans les valeurs d'URL et de stockage. À mesure que les frameworks déplacent davantage de logique vers le navigateur, les sinks DOM se multiplient, et une seule affectation non sécurisée à innerHTML dans un composant largement utilisé peut exposer chaque page qui l'affiche.
Prévenez le XSS DOM en tenant les données non fiables à l'écart des sinks dangereux : préférez textContent à innerHTML, évitez eval et les anciennes méthodes d'écriture de document, et faites passer tout HTML que vous devez insérer par un sanitizer de confiance ou par la Sanitizer API du navigateur et Trusted Types. La liaison de données des frameworks et une Content Security Policy réduisent la surface restante. cside ne réécrit pas la logique DOM de votre application, mais il surveille ce qui s'exécute dans le navigateur à l'exécution. Son méthode Script analyse les charges utiles des scripts third-party, peut bloquer les comportements malveillants et enregistre ce qui a réellement été exécuté, de sorte qu'un script injecté ou compromis tentant une exfiltration est détecté par son comportement plutôt que par sa source, et cette preuve répond à PCI DSS 6.4.3 et 11.6.1.
Dans le XSS réfléchi, le serveur injecte la charge utile dans le HTML qu'il renvoie. Dans le XSS basé sur le DOM, la réponse du serveur est propre, et la faille réside dans le JavaScript côté client qui lit une valeur contrôlée par l'attaquant et l'écrit dans un sink dangereux. L'exploitation peut vivre dans le fragment d'URL, que le serveur ne reçoit jamais.
Parce que la charge utile n'atteint souvent jamais le serveur. Les valeurs placées après le dièse dans une URL restent dans le navigateur, et d'autres sources comme le stockage local ou le référent sont traitées uniquement côté client. Un pare-feu n'inspecte que le trafic qu'il voit, il est donc aveugle aux attaques exécutées entièrement au sein du DOM.
We answer client-side security questions every day. Bring yours.