XSS Réfléchi.

Le XSS réfléchi (non persistant, Type 1) se produit lorsqu'une application web prend des données issues d'une requête HTTP — souvent un paramètre d'URL ou un champ de formulaire — et les renvoie dans la réponse sans encodage de sortie adéquat. L'attaque requiert que la victime clique sur un lien forgé, c'est pourquoi elle est généralement diffusée par hameçonnage, malvertising ou messagerie. Une exploitation réussie permet de voler des cookies de session, d'agir au nom de l'utilisateur ou de mener à un compromis complet du compte. Les défenses incluent l'encodage HTML contextuel, une Content Security Policy stricte et les frameworks qui échappent automatiquement les sorties.

Anatomie d'une attaque XSS réfléchi

flowchart LR
  A[L'attaquant forge un lien avec un script dans un parametre] --> B[Diffusion via phishing / pub / chat]
  B --> C[La victime clique sur le lien]
  C --> D[L'app reflete l'entree sans encodage]
  D --> E[Le navigateur execute le script dans la session]
  E --> F[Vol de cookie / actions au nom de l'utilisateur / prise de compte]

Pourquoi le payload doit être encodé selon son contexte

La subtilité déterminante du XSS est que l'« encodage » dépend du contexte : la même valeur est sûre dans un emplacement et dangereuse dans un autre. Une donnée placée dans du texte HTML nécessite un encodage d'entités HTML ; dans un attribut, un encodage d'attribut et des guillemets ; dans un bloc <script> ou un gestionnaire d'événement, un encodage de chaîne JavaScript ; et dans une URL, un encodage d'URL. Un unique passage d'encodage appliqué aveuglément manquera les cas où le même paramètre est reflété dans plusieurs contextes. Les moteurs de templates qui échappent par défaut (JSX de React, Angular, ou le templating côté serveur avec échappement contextuel) éliminent la plupart des XSS réfléchis, à condition d'éviter les échappatoires comme dangerouslySetInnerHTML ou innerHTML.

Les filtres côté navigateur ne sont plus une défense. Google a supprimé le XSS Auditor de Chrome dans Chrome 78 (octobre 2019) car il était facilement contournable, source de faux positifs, et pouvait lui-même être détourné pour désactiver sélectivement des scripts légitimes ; l'en-tête X-XSS-Protection qu'il honorait est désormais de fait obsolète. Les contrôles durables sont l'encodage de sortie contextuel, une Content Security Policy stricte (idéalement à base de nonce ou de hash), des cookies HttpOnly pour qu'un script volé ne puisse pas lire la session, et la validation d'entrée comme défense en profondeur plutôt que comme barrière principale.