Cross-Site Scripting (XSS) : vecteurs d'attaque et défenses

Pourquoi XSS hante encore les applications web

Le cross-site scripting (XSS) reste l'une des vulnérabilités web les plus répandues. Malgré une prise de conscience généralisée, il figure systématiquement dans le Top 10 de l'OWASP. Le problème central : les applications font confiance aux entrées utilisateur et les affichent sans traitement approprié. Les attaquants injectent des scripts malveillants qui s'exécutent dans le navigateur des victimes, entraînant le détournement de session, le vol de données et la défiguration.

Cet article décompose les vecteurs d'attaque XSS et fournit des défenses pratiques que vous pouvez mettre en œuvre dès aujourd'hui.

Qu'est-ce que le XSS et comment ça marche ?

Le XSS se produit lorsqu'une application inclut des données non fiables dans une page web sans validation ni encodage. Le navigateur exécute alors le script injecté comme s'il faisait partie du site légitime. Comme le script s'exécute dans le contexte du site vulnérable, il peut accéder aux cookies, au stockage local et effectuer des requêtes au nom de l'utilisateur.

Prenons une simple page de recherche qui reflète la requête :

<?php echo 'You searched for: ' . $_GET['q']; ?>

Si un attaquant forge une URL comme search.php?q=<script>alert('XSS')</script>, le script s'exécute lorsque la victime visite le lien.

Trois principaux types de XSS

1. XSS réfléchi (Reflected)

Le script malveillant fait partie de la requête (par exemple, un paramètre d'URL) et est immédiatement reflété dans la réponse. Les victimes doivent être incitées à cliquer sur un lien ou à soumettre un formulaire. Ce type est souvent utilisé dans les campagnes de phishing.

2. XSS stocké (Stored)

Le script est stocké de manière permanente sur le serveur (par exemple, dans une base de données, un champ de commentaire ou un profil utilisateur). Chaque visiteur de la page affectée exécute le script. Le XSS stocké est plus dangereux car il ne nécessite aucune interaction au-delà de la consultation de la page.

3. XSS basé sur le DOM (DOM-based)

La vulnérabilité existe dans le JavaScript côté client qui lit des données à partir d'une source non fiable (comme location.hash) et les écrit dans le DOM sans traitement sécurisé. Le serveur peut ne jamais voir la charge utile malveillante.

document.getElementById('output').innerHTML = location.hash.substring(1);

Si le hash contient <img src=x>, le script s'exécute.

Vecteurs d'attaque courants

• Entrée utilisateur non échappée dans le HTML : Injection directe dans le contenu HTML, les attributs ou le JavaScript.
• Utilisation incorrecte de fonctions dangereuses : Fonctions comme innerHTML, document.write, eval et setTimeout avec des arguments de type chaîne.
• Injections basées sur l'URL : Manipulation des attributs href, src ou style avec des URI javascript:.
• Composants tiers : Bibliothèques ou widgets vulnérables qui affichent des données non fiables.

Défenses contre le XSS

1. Encodage de sortie (échappement contextuel)

Encodez toutes les données non fiables avant de les afficher dans le HTML, les attributs, le JavaScript, le CSS ou les URL. Utilisez un encodage adapté au contexte :

• Encodage d'entités HTML : Convertissez &, <, >, ", ' en entités.
• Encodage JavaScript : Échappez les caractères non alphanumériques en Unicode.
• Encodage URL : Utilisez encodeURIComponent() pour les paramètres de requête.

La plupart des frameworks modernes (React, Angular, Vue) échappent automatiquement par défaut, mais soyez prudent avec dangerouslySetInnerHTML ou des mécanismes similaires.

2. Validation et assainissement des entrées

Validez les entrées côté serveur à l'aide de listes blanches. Pour le texte enrichi, utilisez une bibliothèque comme DOMPurify pour assainir le HTML, en supprimant les balises et attributs dangereux.

const clean = DOMPurify.sanitize(userInput);

Ne vous fiez jamais uniquement à la validation côté client.

3. Content Security Policy (CSP)

La CSP est un mécanisme puissant de défense en profondeur. Elle restreint les sources de scripts exécutables, les scripts en ligne et d'autres ressources. Une CSP stricte peut bloquer le XSS même si une injection se produit.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none';

Évitez unsafe-inline et unsafe-eval. Utilisez des nonces ou des hachages pour les scripts en ligne légitimes.

4. Attributs de cookies sécurisés

Définissez les cookies avec HttpOnly (empêche l'accès JavaScript) et Secure (HTTPS uniquement). Cela atténue le détournement de session via XSS.

5. Utilisez des frameworks modernes et évitez les API dangereuses

Des frameworks comme React, Angular et Vue échappent automatiquement les données. Évitez la manipulation directe du DOM avec innerHTML. Si vous devez insérer du HTML, assainissez-le d'abord.

6. Tests de sécurité réguliers

Intégrez SAST, DAST et des tests d'intrusion manuels. Des outils comme OWASP ZAP peuvent aider à identifier les vulnérabilités XSS.

Comparaison des types de XSS et des principales défenses

Étape par étape : mettre en œuvre les défenses XSS

1. Identifiez tous les points d'entrée : Formulaires, paramètres d'URL, en-têtes, cookies.
2. Appliquez un encodage de sortie contextuel : Utilisez des fonctions intégrées ou des bibliothèques comme OWASP Java Encoder.
3. Assainissez le texte enrichi : Utilisez DOMPurify ou similaire.
4. Déployez CSP : Commencez par le mode rapport uniquement, puis appliquez.
5. Définissez les cookies HttpOnly et Secure.
6. Formez les développeurs : Sensibilisez aux pratiques de codage sécurisé.
7. Testez régulièrement : Intégrez les tests de sécurité dans le CI/CD.

FAQ

Quelle est la différence entre XSS et CSRF ?

XSS exécute des scripts malveillants dans le navigateur de la victime, tandis que CSRF incite le navigateur à envoyer des requêtes non autorisées à un site où l'utilisateur est authentifié. XSS peut être utilisé pour contourner les protections CSRF.

Une Content Security Policy peut-elle complètement prévenir le XSS ?

Non, CSP est une mesure de défense en profondeur. Elle réduit considérablement les risques mais ne peut pas remplacer un encodage de sortie et une validation des entrées appropriés. Une CSP mal configurée peut encore permettre certaines attaques.

La validation côté client suffit-elle pour prévenir le XSS ?

Non. La validation côté client peut être facilement contournée. Validez et encodez toujours côté serveur, et traitez toutes les données client comme non fiables.

Conclusion

XSS est une menace persistante, mais avec une stratégie de défense en couches—encodage de sortie, validation des entrées, CSP et cookies sécurisés—vous pouvez efficacement l'atténuer. Restez vigilant, maintenez vos frameworks à jour et testez en continu.

Pour des outils de sécurité supplémentaires, consultez notre Analyseur de logs Nginx pour détecter des modèles suspects dans vos logs serveur.