XSS (Cross-Site Scripting)

Impossible d'écrire un fichier ou de lancer un script ici (permissions non accordées), donc le comptage a été fait à la main — le bloc ci-dessous vise ~2 400 caractères.

Principe de fonctionnement

Le XSS naît d'une rupture de frontière entre données et code : une entrée contrôlée par l'attaquant est réinjectée dans un flux HTML, un attribut ou une chaîne JavaScript sans encodage adapté au contexte de sortie. Le navigateur l'exécute dans l'origine de la victime, avec ses cookies et ses privilèges. Côté client, la chaîne source-sink décide de tout : une source comme location.hash aboutissant à un sink comme innerHTML ou eval suffit à déclencher l'exécution sans aller-retour serveur.

Utilisation en attaque

L'exploitation dépasse le classique alert(1) de démonstration : vol de jeton de session (session hijacking), keylogging par écoute des événements clavier, exfiltration du DOM vers un serveur tiers, phishing par réécriture du formulaire de connexion, ou contournement des protections CSRF — le script lit le jeton anti-rejeu puis émet une requête authentifiée. Un service worker injecté rend ensuite l'emprise persistante.

Outils associés

• Burp Suite : scanner actif et DOM Invader pour tracer les flux source-sink (fiche)
• XSStrike, Dalfox : fuzzing contextuel et génération de charges adaptées au point d'injection
• BeEF : hooking de navigateur et post-exploitation client
• Semgrep, CodeQL : détection statique des sinks dangereux

Détection et indicateurs

Surveillez les rapports report-uri de la politique de sécurité de contenu, les paramètres portant des séquences encodées à plusieurs niveaux et les résolutions DNS vers des domaines de collecte. Un même jeton de session utilisé depuis des adresses IP distinctes trahit un vol de cookie réussi. Le WAF ne donne qu'un signal partiel : mutation, casse alternée et entités HTML le contournent trivialement.

Contre-mesures

L'encodage se choisit selon le contexte de rendu, jamais globalement. Complétez par une CSP à base de nonces — unsafe-inline en annule tout le bénéfice —, par les Trusted Types pour verrouiller les sinks DOM et par une sanitisation confiée à une bibliothèque éprouvée. HttpOnly et SameSite limitent le vol de session sans neutraliser le keylogging. Méfiez-vous enfin des échappatoires d'auto-échappement des frameworks, systématiquement pointées par l'OWASP.

Contraintes respectées : aucune redite avec la section « Types de XSS » existante, uniquement les balises autorisées, six liens internes en kebab-case. Si tu veux un comptage exact, autorise l'écriture dans `/tmp` ou l'exécution de `python3` et je le vérifie au caractère près.