XSS Cheat Sheet : Un guide axé sur la recherche avec intégration de Penligent en un clic

Résumé

Les scripts intersites (XSS) restent l'une des vulnérabilités web les plus répandues et les plus dangereuses. Les frameworks frontaux modernes, les SPA (applications à page unique) et les riches écosystèmes de scripts tiers augmentent à la fois les opportunités et la complexité. Cet article fusionne l'aide-mémoire de l'OWASP sur la prévention des XSS avec des recherches universitaires et industrielles récentes, formant une stratégie de défense en couches : encodage contextuel, assainissement HTML, suivi dynamique des taches pour les XSS DOM, analyse différentielle, politique de sécurité du contenu (CSP) et contrôles de la chaîne d'approvisionnement. Nous proposons en outre une conception pour un Analyse XSS en un clic Ce document a été conçu pour être inclus directement dans des livres blancs d'ingénierie ou dans la documentation d'un produit. Ce document peut être inclus directement dans les livres blancs d'ingénierie ou dans la documentation du produit.

Motivation

Les vulnérabilités XSS permettent aux attaquants d'injecter des scripts exécutables dans des pages web par ailleurs inoffensives, s'exécutant effectivement dans le navigateur de la victime avec les privilèges du domaine du site. Ces attaques peuvent permettre d'exfiltrer des données sensibles (cookies, localStorage), d'effectuer des actions non autorisées ou de défigurer le contenu. (MDN Web Docs)

Malgré des décennies de sensibilisation et de techniques d'atténuation, le XSS reste un risque persistant. L'augmentation du rendu côté client, des cadres JavaScript dynamiques, des scripts tiers et des systèmes de templates de plus en plus complexes ont rendu plus difficile la garantie de l'exactitude.

Objectifs de ce guide :

• Combinez les règles pratiques de l'OWASP Cheat Sheet, qui fait autorité, avec les recherches universitaires et techniques les plus récentes.
• Proposer une architecture de défense robuste et multicouche plutôt qu'une seule solution miracle.
• Présenter une conception concrète pour Penligent afin de fournir un service d'assistance à la clientèle. Analyse XSS en un clic qui fait le lien entre la recherche et le produit.

Fondations : Encodage contextuel et puits de sécurité

L'un des principes fondamentaux de la prévention des XSS est le suivant : ne jamais permettre à des données brutes non fiables d'atteindre un contexte exécutable sans encodage ou assainissement approprié. L'encodage doit être adapté au contexte (corps HTML, attribut, littéral JavaScript, CSS ou URL). C'est l'essence même de l'aide-mémoire de l'OWASP sur la prévention des XSS. (cheatsheetseries.owasp.org)

Règles d'encodage des sorties contextuelles

En pratique, préférez toujours les bibliothèques d'encodage intégrées ou bien testées. Évitez de créer vos propres remplacements ad hoc.

Des puits sûrs et des API dangereuses à éviter

Même avec un encodage correct, certaines API sont intrinsèquement risquées. Voici quelques exemples de puits dangereux :

• innerHTML, outerHTML
• document.write, document.writeln
• eval(), Fonction() constructeur
• Les gestionnaires d'événements en ligne (par ex. onclick="..." avec un contenu dynamique)

Préférer les alternatives sûres :

• .textContent ou .innerText pour l'insertion de texte
• element.setAttribute() (pour les noms d'attributs contrôlés)
• Les méthodes DOM (par exemple appendChild, créer un élément) sans concaténation de chaînes

Assainissement du HTML lorsque le HTML riche est nécessaire

Dans les scénarios où le contenu fourni par l'utilisateur est autorisé à inclure du HTML (par exemple, les éditeurs WYSIWYG, les commentaires avec un balisage limité), l'assainissement est nécessaire. L'approche de base est la suivante :

1. Liste blanche les balises, les attributs et les modèles de valeur d'attribut autorisés.
2. Utiliser des bibliothèques matures (par exemple DOMPurify) plutôt que des expressions rationnelles personnalisées et fragiles.
3. Soyez conscient de ce qui suit attaques différentielles par analyse syntaxiqueLe comportement de l'analyseur peut différer de celui de l'analyseur HTML du navigateur, ce qui peut entraîner des contournements.

Une ligne de recherche connue démontre comment les assainisseurs et les navigateurs peuvent diverger dans l'interprétation des marques de majuscules, permettant des évasions par le biais d'une tokenisation alternative. (Voir la recherche "Parsing Differentials")

Détection des XSS basés sur DOM via le suivi des erreurs d'exécution (Runtime Taint Tracking)

Les techniques côté serveur ne permettent pas d'attraper de manière fiable DOM XSS (injection côté client), car le puits concerné peut se trouver dans le JavaScript après le chargement de la page. Le suivi dynamique des taches (marquage des sources non fiables et surveillance de la propagation) est une méthode bien étudiée.

• TT-XSS (par R. Wang et al.) est une implémentation classique de la détection DOM XSS basée sur l'altération dynamique. (科学直通车)
• Parler de ma génération utilise l'analyse dynamique des flux de données pour générer des exploits DOM XSS ciblés. (ResearchGate)
• TrustyMon (2025) démontre un système pratique de surveillance de l'exécution qui peut détecter les XSS basés sur le DOM dans les applications du monde réel avec une grande précision et peu de faux positifs. (Bibliothèque numérique de l'ACM)

Ces systèmes instrumentent l'exécution côté client, marquent les entrées non fiables (par exemple, hachage d'URL, paramètres de requête, éléments DOM) et détectent lorsqu'elles atteignent des puits dangereux (par exemple, le système de gestion de l'information). innerHTML) d'une manière qui entraîne l'exécution du script.

Une mise en garde s'impose : le suivi de l'exécution a un coût en termes de performances. Certains travaux combinent ML/DNN comme préfiltre pour réduire la charge de travail liée à la détection des taches. Par exemple, Melicher et al. proposent d'utiliser l'apprentissage profond pour pré-classifier les fonctions vulnérables probables et n'appliquer le suivi des taches qu'à ces fonctions. (contrib.andrew.cmu.edu)

Exemple A - Evier fixe (utiliser un évier sûr) texteContenu)

<html>
  <head><title>Bienvenue</title></head>
  <body>
    <h1>Bonjour !</h1>
    <div id="greeting"></div>
    <script>
      function getQueryParam(name) {
        return new URLSearchParams(window.location.search).get(name);
      }
      var raw = getQueryParam("name") || "";
      // Use textContent to insert as plain text (safe)
      document.getElementById("greeting").textContent = raw;
    </script>
    <p>Bienvenue sur notre site.</p>
  </body>
</html>

Pourquoi c'est sûr : texteContenu écrit du texte en clair ; même si brut contient <script>…</script>il sera rendu sous forme de texte et non exécuté. L'utilisation de URLSearchParams évite l'analyse fastidieuse des index/sous-chaînes. portswigger.net

Exemple B - Puits d'attributs et gestion sûre des URL (pseudo-puits href)

Modèle vulnérable :

// Vulnérable :
var params = new URLSearchParams(window.location.search) ;
var target = params.get("url") ; // contrôlé par l'utilisateur
document.getElementById("mylink").href = target ;

Si cible est un code javascript, le fait de cliquer sur le lien exécute le JS.

Modèle sûr (valider le schéma) :

function safeHref(input) {
  try {
    var u = new URL(input, window.location.origin);
    if (u.protocol === "http:" || u.protocol === "https:") {
      return u.toString();
    }
  } catch(e) { /* invalid URL */ }
  return "#";
}
document.getElementById("mylink").href = safeHref(params.get("url"));

Explication : nouvelle URL() se normalise ; nous n'autorisons que http :/https : des schémas. Cela bloque javascript :/données : des schémas. portswigger.net

Politique de sécurité du contenu (PSC) : La défense en profondeur

Bien que le codage et l'assainissement soient les principales défenses, le CSP fournit un moyen de protection contre la fraude. une barrière secondaire solide. Un CSP bien configuré utilisant des nonces ou des hachages, ainsi que des strict-dynamique et l'élimination des 'unsafe-inline' (non sécurisé en ligne)peut grandement limiter l'exploitation de XSS.

Cependant, des pièges existent :

• Réutilisation de nonce: Certains sites réutilisent le même nonce dans plusieurs réponses, ce qui affaiblit les protections du CSP. Une étude récente intitulée "The Nonce-nce of Web Security" montre que c'est ce que font de nombreux sites dans le monde réel. (arXiv)
• Complexité du déploiement : la prise en charge des scripts en ligne existants, des bibliothèques tierces et des incohérences des navigateurs conduit souvent à un assouplissement des politiques.

La PSC doit donc compléter, et non remplacer, l'encodage et l'assainissement.

Meilleures pratiques d'ingénierie : CI, Lint, Testing, Monitoring

Pour rendre opérationnelles des défenses robustes contre les XSS :

• ESLint / Linters de codeInterdire ou signaler l'utilisation de puits non autorisés (innerHTML, eval), exiger des annotations de contexte sur les expressions de modèle.
• Analyse statique et dynamique dans l'IC:
  • Analyse statique multi-fichiers pour les modules JS
  • Tests Fuzz ou tests d'analyse différentielle
  • L'instrumentation de l'exécution dans les environnements d'essai
• Tests unitaires / de sécuritéles tests unitaires : générer des charges utiles contextuelles dans les tests unitaires pour s'assurer que le codage correct est appliqué (comme dans "Automated Detecting & Repair of XSS Vulnerabilities" ou "Detecting XSS via Unit Testing") (arXiv)
• Surveillance et alerteLe système de gestion de l'information (CSP) : il recueille les rapports de violation du CSP, les alertes d'exécution instrumentées pour les flux suspects, les mesures de journal des échecs d'encodage.

Conception de l'analyse XSS en un clic de Penligent

Vous trouverez ci-dessous une proposition de spécification de conception que vous pouvez intégrer dans le produit de Penligent en tant que Analyse XSS en un clic "Playbook" (en anglais).

Workflow des tâches (haut niveau)

1. Rendu Crawl & JS - découvrir toutes les pages et les itinéraires pilotés par JS.
2. Analyse statique - la propagation de l'altération sur le code source afin de localiser les puits et les fonctions à haut risque.
3. Numérisation des modèles - utiliser des scanners modèles (par exemple Nuclei) pour envoyer des charges utiles XSS courantes.
4. Exécution / analyse dynamique - en utilisant la navigation sans tête et l'instrumentation, injecter des charges utiles et détecter l'exécution de scripts.
5. Suivi des erreurs d'exécution - instrumenter la durée d'exécution de la page et surveiller si des données non fiables atteignent des puits dangereux.
6. Parsing-differential fuzz test - transmettre les balises de cas extrêmes à l'assainisseur et au navigateur et détecter les divergences.
7. Audit CSP & SRI - inspecter les en-têtes, les balises de script, vérifier la réutilisation du nonce, les attributs d'intégrité manquants.
8. Génération de rapports - rassembler les vulnérabilités avec des PoC, une évaluation des risques, des suggestions de remédiation et, éventuellement, générer des correctifs pour les PR.

Modèle d'échantillon de noyau (XSS réfléchi)

id : xss-reflect-basic
info :
  nom : XSS réfléchi basique
  auteur : penligent-scan
  severity : high
requests :
  - method : GET
    path :
      - "{{BaseURL}}?q={{payload}}"
    payloads :
      payload :
        - ""
    matchers :
      - type : word
        part : body
        words :
          - ""

Vous pouvez développer des ensembles de données utiles en fonction du contexte (attribut, JS, URL) et enchaîner avec la vérification sans tête afin de réduire les faux positifs.

Exemple de définition de tâche (JSON)

{
  "name" : "XSS QuickScan",
  "étapes" : [
    {"id" : "crawl", "type" : "crawler", "params" : {"start_url" : "{{target}}", "render_js" : true}},
    {"id" : "static", "type" : "static_analysis", "deps" : ["crawl"], "params" : {"analyzers" : ["multi-file-taint"]}},
    {"id" : "template_scan", "type" : "scanner", "deps" : ["crawl"], "params" : {"templates" : ["xss-reflect-basic"]}},
    {"id" : "dynamic", "type" : "dynamic_scan", "deps" : ["template_scan", "static"], "params" : {"engine" : "headless-instrumented"}},
    {"id" : "dom_taint", "type" : "runtime_taint", "deps" : ["dynamic"], "params" : {"agent" : "instrumented-browser"}},
    {"id" : "parsing_diff", "type" : "parsing_diff", "deps" : ["dynamic"], "params" : {}},
    {"id" : "audit_csp", "type" : "csp_audit", "deps" : ["crawl"], "params" : {}},
    {"id" : "report", "type" : "report_gen", "deps" : ["dom_taint", "parsing_diff", "audit_csp"], "params" : {"format" : "pdf,html"}}
  ]
}

Rapport et résultats

Chaque résultat comprend

• Type (réfléchi / stocké / DOM)
• Preuve de concept (requête/réponse HTTP, instantané DOM, capture d'écran)
• Score de gravité
• Suggestions de corrections (par exemple, encodeur correct, configuration du sanitizer, utilisation sûre de l'API)
• Génération automatique d'un patch ou d'un squelette de RP en option

Vous pouvez également établir un lien avec la littérature pertinente (par exemple en citant TrustyMon, en analysant des articles différentiels) dans le rapport technique interne.

Exemples d'extraits de code et de bonnes pratiques

Voici quelques exemples de snippets sûrs et non sûrs dans un contexte de type React :

Peu sûr (vulnérable)

import DOMPurify from 'dompurify' ;
function UserGreeting(props) {
  const clean = DOMPurify.sanitize(props.userContent, { ALLOWED_TAGS : ['b', 'i', 'u', 'a'], ALLOWED_ATTR : ['href'] }) ;
  retour <div dangerouslysetinnerhtml="{{" __html: clean }} />;
}

function UserGreeting(props) {
  return <div>{props.userContent}</div>; // React s'échappe automatiquement
}

// Unsafe
<img src={userInput} />

// Safer
function safeUrl(u) {
  const doc = new URL(u, window.location.origin);
  if (doc.protocol === 'http:' || doc.protocol === 'https:') {
    return doc.toString();
  }
  return '/';  // fallback
}
<img src={safeUrl(userInput)} />