XSS Cheat Sheet : un guide pratique pour les ingénieurs en sécurité les plus acharnés

Pourquoi une autre antisèche xss est-elle encore importante ?

Cadres modernes ≠ sans XSS. L'auto-capsule dans React/Angular/Svelte réduit les trous dans le templating, mais les systèmes réels continuent d'expédier des API DOM mal utilisées, des widgets tiers non sûrs, des Markdown/WYSIWYG permissifs, javascript : Les gestionnaires d'URL, SVG/MathML, les restes de JSONP et la confiance implicite dans les systèmes d'information de l'UE. localisation/hachage/postMessage.

Les écosystèmes vectoriels évoluent. PortSwigger annote en permanence les charges utiles en événement / balise / attribut / navigateurréduisant ainsi considérablement la "mémoire tribale". Cette curation est précieuse lorsque vous avez besoin d'une large couverture sans avoir à réinventer les taxonomies des charges utiles.

Le filtrage à lui seul ne constitue pas une défense. L'OWASP le répète depuis plus d'une décennie : la correction dépend de le contexte de rendu des données. Combinaison encodage correct de la sortie, assainissement (pour le HTML rédigé par l'utilisateur), politique (CSP, Trusted Types), et cadre d'hygiène n'est pas négociable.

Matrice surface d'attaque × contexte

Utilisez cette matrice comme votre liste de contrôle de l'exécution lors de l'écriture de validations Playwright/Burp/Nuclei ou d'audits de code. Chaque ligne correspond à un rendu contexte à risque éviers, commun entrées, le premier mouvement défensifet comment vérifier à l'échelle.

Exemples minimaux reproductibles (EMR) que vous pouvez réellement exécuter

1) Contexte de l'attribut + déclencheur à interaction nulle

<input autofocus onfocus="fetch('/beacon?xss=1')">

Pourquoi c'est important : Les événements Focus se déclenchent automatiquement au chargement dans de nombreux flux UX (champs de recherche, invites rapides). Remplacer par <svg onload=…> ou <img onerror="…"> pour tester différentes sémantiques de déclenchement.

2) Support SVG + bizarreries dans la gestion des URL

<svg><a xlink:href="javascript:fetch('/beacon?svg')">x</a></svg>

Pourquoi c'est important : SVG est un espace de noms XML distinct avec une analyse d'attributs historiquement excentrique. Les équipes oublient souvent d'assainir le SVG ou de l'autoriser dans les moteurs de rendu Markdown.

3) XSS basé sur DOM (source → sink lineage)

<script>
  const q = new URL(location).hash.slice(1);
  document.getElementById('out').innerHTML = q; // sink
</script>
<div id="out"></div>

Pourquoi c'est important : L'anti-modèle classique "lire à partir de l'URL, écrire dans le DOM". Il est omniprésent dans les anciens sites et les outils internes. Corriger avec encodage contextuel et ne jamais écrire directement sur les éviers HTML.

Ligne de base défensive (l'ingénierie d'abord, pas de slogans)

1. Encodage de sortie par contexte. Encoder pour HTML / Attribut / URL / JS respectivement. L'auto-capsulage du cadre ne couvre pas DOM roulés à la main des mises à jour.
2. Assainissement de la liste d'autorisations pour le code HTML de l'utilisateur. Lorsque la logique d'entreprise nécessite un contenu riche (commentaires, biographies, bases de connaissances), il convient d'utiliser DOMPurify (ou équivalent) avec des configurations renforcées ; évitez de "couper les mots" dans les listes noires.
3. Politique de sécurité du contenu. Commencer par script-src 'self' + bloc en ligne par défaut ; définir object-src "none" (aucun) et base-uri "none" (aucun). Adopter Types de confiance dans Chromium pour forcer les API DOM sûres à la compilation et au moment de l'exécution.
4. Audit d'API dangereux. Interdiction ou barrière eval/new Function/setTimeout(string) et les conversions dynamiques JSON→code. Appliquer les règles ESLint lors de la construction et faire échouer l'IC lorsque des violations apparaissent.
5. Test et vérification selon le code. Automatiser la relecture des données utiles. Jumeler avec Rapport d'infraction à la DSP et corrélation passerelle/log pour séparer les "popups démonstratifs" des exploitable les voies qui comptent pour l'entreprise.

De l'antisèche au pipeline : l'automatisation au service des entreprises

Le chemin le plus court entre la "bibliothèque de vecteurs" et la "garantie de qualité de production" est une boucle à cinq étapes :

1. Découverte du contexte. Analyses statiques (règles ESLint, grep sémantique) + sondes d'exécution qui marquent les puits potentiels (innerHTMLles attributs, les points de navigation).
2. Planification vectorielle. Associer chaque puits/contexte à un piscine aménagée de charges utiles (événements d'attributs, bizarreries de balises, gestionnaires d'URL), filtrage par navigateur et drapeaux de fonctionnalités.
3. Épreuve sans tête. Playwright/Chromium fonctionne par vecteur. Console de capture, réseau, Violations de la DSPet les mutations DOM.
4. Corrélation des signaux. Rejoignez les conclusions sans tête avec Passerelle API et journaux d'application pour classer le "bruit" par rapport au "réel". Cela permet d'éliminer les faux positifs dès le premier jour.
5. Des rapports fondés sur des données probantes. Joignez automatiquement des captures d'écran, des traces HTTP, des différences DOM avant/après et des violations de règles. score de confiance afin que les ingénieurs sachent par où commencer.

Rejoueur Minimal Playwright (snippet drop-in)

import { chromium } from 'playwright' ;

const vectors = [
  '#\"&gt;<img src="x" onerror="fetch(\">',
  '#<svg onload="fetch(\">'
] ;

(async () =&gt; {
  const browser = await chromium.launch() ;
  const page = await browser.newPage() ;
  page.on('console', m =&gt; console.log('console:', m.text())) ;
  page.on('pageerror', e =&gt; console.error('pageerror:', e)) ;
  for (const v of vectors) {
    await page.goto('https://target.example/' + v) ;
    await page.screenshot({ path : `evidence_${encodeURIComponent(v)}.png` }) ;
  }
  await browser.close() ;
})() ;

Produisez-le : ajouter des étiquettes de lignées source→sink à chaque série, activer les étiquettes de lignées source→sink Rapport du CSP uniquement pour collecter les infractions et les stocker Différences DOM pour rendre les régressions évidentes dans les PR.

Réalités du cadre pour lesquelles vous devez concevoir

• React/JSX. L'écrêtage automatique est utile, mais dangereusementSetInnerHTML et brut ref.current.innerHTML = ... rouvrir l'évier. Traitez-les comme des odeurs de code ; protégez-les avec un désinfectant et une politique des types de confiance.
• Angulaire. Le désinfectant est correct, mais bypassSecurityTrustHtml et des API similaires peuvent percer des trous, documenter chaque contournement et restreindre l'accès aux sources approuvées.
• Prochain/Nuxt/SSR. Les pages générées par le serveur ne doivent faire écho qu'à codé le contenu. Ne comptez jamais sur les cadres clients pour "nettoyer" les erreurs du serveur.
• Markdown/MDX/WYSIWYG. Les traiter comme Ingestion HTML problèmes. Durcissez votre moteur de rendu, mettez en bac à sable les widgets non fiables et purgez les attributs d'événements/gestionnaires d'URL.
• SVG/MathML. Si vous devez les autoriser, plafonnez l'ensemble des fonctionnalités et utilisez un outil d'assainissement qui comprend les espaces de noms XML. S'ils ne sont pas critiques, convertissez-les en trame sûre sur le serveur.

Familles de charge utile pratiques dont vous aurez réellement besoin

• Déclencheur automatique sur événement : autofocus, onload, en cas d'erreur, onanimationstart, onfocus, onpointerenter. Idéal pour prouver l'exploitabilité sans clics de l'utilisateur.
• Gestionnaires d'URL : javascript :, données :et occasionnellement vbscript : (ancienne version). Appliquer les listes d'autorisation.
• Collisions de modèles : Les astuces de découpage/concat qui échappent aux filtres naïfs (par exemple, sortir des contextes d'attributs puis réintroduire le HTML).
• DOM clobbering : Remplacer les identifiants/noms pour rediriger les chemins de code et faire atterrir un puits.
• Temps de réaction entre la mutation et l'observateur : Déclencheurs qui exploitent les mises à jour dynamiques au lieu du chargement initial.

CSP et types de confiance : de "l'utile à l'agréable" au garde-fou

• CSP vous offre un langage de politique pour limiter les sources de scripts et l'exécution en ligne. Commencez par des règles strictes, puis élargissez-les uniquement pour les cas vérifiés. Associer avec rapport-uri/rapporter à et récolter rapports d'infraction dans votre télémétrie.
• Types de confiance obliger les développeurs à passer politique créée dans les API DOM qui, autrement, accepteraient des chaînes brutes (innerHTML, outerHTML, insertAdjacentHTML, Gamme1TP5CréerUnFragmentContextuel). Cela permet d'éliminer des classes entières de DOM XSS par construction.
• Conseil de déploiement : faire fonctionner le CSP en rapport uniquement pendant deux sprints ; corriger les violations ; puis appliquer. Introduire un Politique des types de confiance à l'échelle de l'application et ne délivrer que du HTML "béni" par l'intermédiaire de constructeurs agréés.

Comment prouver l'exploitabilité aux ingénieurs

1. Scripts de reproduction: Fournir un one-liner (URL ou curl) et une branche Playwright à rejouer.
2. Différence DOM: Indiquer le nœud exact qui a changé et le chemin (#app > .profile > .bio).
3. Piles d'appel: Pour les puits de JS, incluez les traces d'empilement de votre eval/Fonction crochets.
4. Preuves du CSP: Attachement de JSON de violation pour les violations de src inline/script.
5. Récit d'affaires: "Cela permet d'exfiltrer des jetons de session à partir de /compte par l'intermédiaire d'une <img> beacon" bat "alert popped" à tous les coups.

Exécution de l'aide-mémoire xss à l'intérieur de Penligent

Si vous utilisez déjà Penligent en tant que plateforme automatisée de pentest, vous pouvez regrouper les éléments ci-dessus en un seul modèle exécutable :

• Modèle de tâche : "Recon XSS + Valider". L'agent effectue une reconnaissance (sous-domaine/port/empreinte digitale), planifie les vecteurs en fonction du contexte détecté, exécute une relecture sans tête, et met en corrélation les signaux avec des rondins ou des passerelles pour réduire le bruit.
• L'exportation de preuves d'abord. Les résultats sont expédiés avec scores de confianceLes étapes reproductibles, les captures d'écran, les journaux de violation de la CSP et les différences DOM sont des éléments auxquels vos ingénieurs peuvent se fier.
• Là où il est le plus utile. Des équipes de grande envergure avec des piles mixtes (anciennes et SPA), ou des équipes qui migrent vers des types de CSP/Trusted Types et qui ont besoin d'une assistance technique. triage fondé sur la preuve plutôt que sur la charge utile.

Les pièges les plus fréquents dont sont victimes les équipes expérimentées

• Assainir l'entrée, pas la sortie. Si vous devez accepter le HTML, désinfectez et codent toujours sur la sortie en fonction du contexte de destination ; les deux ne sont pas interchangeables.
• Permettre javascript : pour "flexibilité". Le supprimer entièrement ; ne mettre sur liste blanche que des protocoles spécifiques (https, mailtopeut-être Tel).
• Traiter Markdown comme un "texte sûr". Il s'agit d'un moteur de rendu dont les plugins décident de la sécurité. Vérifier les balises/attributs autorisés ; envisager un tramage côté serveur pour les SVG non fiables.
• Ignorer les contextes non HTML. La concaténation d'URL et les évaluations JSON→JS sont des récidivistes. Renforcer la politique "pas de ficelle pour le code".
• Faire confiance à l'environnement. XSS qui échoue dans headless peut encore réussir sur Chromium mobile ou les anciennes versions de bureau. Conservez un matrice du navigateur pour les applications de grande valeur.

Liste de contrôle de la production, à épingler à côté de votre badge CI

• Conscience du contexte codage utilitaires avec tests unitaires pour HTML/Attr/URL/JS
• DOMPurify (ou équivalent) verrouillé à une configuration renforcée pour les chemins à contenu riche
• CSP avec script-src 'self' (pas de unsafe-inline), object-src "none" (aucun), base-uri "none" (aucun)collecte des infractions reliée à la télémétrie
• Types de confiance politique + règles de contrôle au moment de la construction pour bloquer les chaînes de caractères brutes
• Règles d'interdiction d'ESLint eval/new Function/setTimeout(string) (renforcé par l'IC)
• Dramaturge suite de rediffusion alimenté par des vecteurs de type PortSwigger ; captures d'écran par vecteur + DOM diffs
• Automatisé corrélation des signaux avec les journaux d'application / les événements de la passerelle API
• Des rapports fondés sur des données probantes avec scores de confiance et notes sur l'impact sur les entreprises
• Lignes du modèle de relations publiques : "Introduit de nouveaux éviers HTML ?" "Contourne l'assainisseur ?" "Mise à jour de la politique de TT ?
• Révision régulière des paramètres des widgets tiers/WYSIWYG/Markdown

FAQ

Q : Si nous utilisons déjà React/Angular, avons-nous encore besoin de cela ?
R : Oui. Les frameworks ne contrôlent pas toutes les écritures DOM, les widgets tiers, ou Markdown/SVG. Vous avez toujours besoin de sanitizer + CSP + TT, et vous devez éviter d'écrire des données non fiables dans les puits DOM bruts.

Q : Devrions-nous bloquer tous les scripts en ligne avec CSP ?
R : Oui, par défaut. N'utilisez des nonces ou des hachages qu'en cas d'absolue nécessité et documentez l'exception. L'objectif à long terme est d'éviter complètement les scripts en ligne.

Q : La désinfection est-elle suffisante ?
R : Non. L'assainissement réduit la surface d'attaque pour les Ingestion HTMLmais vous avez toujours besoin d'une codage de sortie et des garde-fous politiques. À problèmes différents, outils différents.

Q : Quels navigateurs testons-nous ?
R : Au minimum, les deux principaux moteurs de votre base d'utilisateurs pour les ordinateurs de bureau et les téléphones portables. Conservez une petite matrice ; certains vecteurs sont spécifiques à un navigateur ou liés à des caractéristiques.

Autres lectures (faisant autorité)

• PortSwigger - Aide-mémoire pour les scripts intersites (XSS) - un catalogue vivant de vecteurs, de PoC et de notes de navigation.
• OWASP - Aide-mémoire pour la prévention des XSS - des stratégies d'encodage rigoureuses et spécifiques au contexte et des tableaux de ce qu'il faut faire ou ne pas faire.
• OWASP - Aide-mémoire pour la prévention des XSS basés sur le DOM - les modèles source→sink et les mesures d'atténuation dans le navigateur.
• PortSwigger - Qu'est-ce qu'un XSS ? - un tutoriel structuré et des laboratoires pratiques pour la formation des nouveaux employés.

Annexe : référence rapide en matière d'assainissement et d'encodage

• Nœuds de texte HTML → échapper & " ' /
• Valeurs des attributs → HTML-attribute encode + disallow event attributes from untrusted data
• URL → coder les composantsprotocoles de la liste d'autorisation ; ne jamais écrire de données brutes javascript : / données :
• Chaînes JS → sérialiser en toute sécurité ; ne jamais transmettre les données de l'utilisateur aux API qui interprètent le code

Note de clôture : Une utilité L'antisèche xss est l'un de ceux que vous pouvez dans votre pipeline-et non une affiche de charges utiles intelligentes. Commencez par la découverte du contexte, planifiez les vecteurs par contexte, rejouez sans tête, mettez en corrélation avec les journaux et envoyez des preuves avec des scores de confiance. Que vous adoptiez Penligent ou que vous mettiez en place votre propre harnais, pilotez le processus avec preuve et laisser la politique faire respecter les garde-fous.