Le cross-site Scripting (XSS) est une vulnérabilité de sécurité généralement trouvée sur les sites Web et/ou les applications Web qui acceptent les entrées des utilisateurs. Les moteurs de recherche, les formulaires de connexion, les forums et les zones de commentaires en sont des exemples.
Table des matières
Attaque par XSS: définition
Les cybercriminels exploitent cette vulnérabilité en entrant des chaînes de code malveillant exécutable dans ces fonctions. Cela injecte le code malveillant dans le contenu du site Web ciblé, en faisant ainsi partie du site Web et lui permettant ainsi d’affecter les victimes qui peuvent visiter ou consulter ce site Web. Le code peut également se présenter comme un contenu transitoire qui ne fait pas réellement partie du site Web, mais semble uniquement être destiné au visiteur. Cela donne l'impression que le site Web est effectivement compromis par des cybercriminels.
Les cybercriminels peuvent également utiliser cette vulnérabilité pour prendre le contrôle ou compromettre directement un site Web, ainsi que pour exploiter d’autres vulnérabilités existantes sur le serveur ou le logiciel du site Web.
Fonctionnement de XSS
- Les cybercriminels choisissent leur site Web cible et analysent ses fonctions vulnérables qui acceptent les commentaires des utilisateurs. Les barres de recherche, les formulaires de connexion et les zones de commentaires en sont des exemples.
- Ils saisissent du code malveillant dans la fonction de leur choix. Le code malveillant peut être écrit à l'aide d'un langage de programmation tel que HTML ou JavaScript, entre autres.
- Le code malveillant est injecté sur la page Web qui résulte de la fonction (résultats de recherche ou commentaire dans une page de commentaires). Il fait ensuite partie de cette page Web, ce qui la compromet.
- Selon la manière dont le code est injecté, le contenu malveillant peut même ne pas se trouver sur la page Web elle-même, mais plutôt en tant qu’élément transitoire qui ne semble faire partie du site Web que pendant l’instance particulière de l’exploitation. Cela peut créer l'illusion que le site Web réel est effectivement compromis, alors qu'il ne l'est pas.
- Les utilisateurs peuvent devenir victimes de la page Web compromise en étant liés à celle-ci par les cybercriminels responsables, ou en trébuchant dessus, selon la fonction que les coupables ont décidé d’abuser.
- Les routines que le code injecté pourrait exécuter sur le système d’une victime peuvent varier, de l’ennui inoffensif au maliciel pur et simple. Il peut être aussi inoffensif qu'une image inattendue affichée parmi le contenu légitimement publié sur ce site Web, vers quelque chose qui redirige l'utilisateur vers un site Web malveillant et/ou télécharge automatiquement des fichiers malveillants sur son système. Il peut également être utilisé pour voler des informations personnelles critiques à la victime, telles que des informations de connexion.
Pourquoi XSS est-il dangereux ?
Avec XSS, les cybercriminels peuvent transformer des sites Web de confiance en sites malveillants, causant ainsi des préjudices et des dommages indéfectibles non seulement aux victimes, mais également à la réputation du propriétaire du site Web de confiance.
Les sites Web compromis par XSS peuvent attaquer le système d'un utilisateur en nombre illimité. Il peut s'agir de tout, du contenu inapproprié affiché au malware téléchargé sur le système sans que l'utilisateur le sache.
Que peuvent faire les utilisateurs ?
Aussi dangereux que XSS soit, il existe des moyens de corriger une telle vulnérabilité. Les propriétaires de sites Web doivent s'assurer que toutes leurs applications Web qui acceptent les entrées des utilisateurs le font de manière à désinfecter d'abord les chaînes saisies avant de créer la page résultante de l'entrée. Cela empêche toute injection de code. Les utilisateurs, en revanche, doivent désactiver les scripts sur leurs navigateurs, et éviter de cliquer sur des liens provenant de parties ou d'expéditeurs suspects.
Les développeurs/propriétaires de sites Web doivent :
- Assurez-vous que toute page de leur site Web qui accepte les entrées utilisateur filtre les entrées de code, telles que HTLM et JavaScript.
- Recherchez les vulnérabilités des applications Web et corrigez-les en conséquence
- Mettez à jour leur logiciel de site Web et de serveur pour empêcher l'exploitation future de vulnérabilités qui peuvent également être ciblées par une attaque XSS.
Les utilisateurs doivent :
- Désactivez les scripts sur les pages où ils ne sont pas requis, ou désactivez-les complètement.
- Évitez de cliquer sur des liens provenant d’emails ou de publications suspects sur des tableaux de messages, car ils peuvent entraîner des pages compromises.
- Accédez aux sites Web souhaités directement via leur adresse, et non via une source ou un lien tiers.
- Mettez régulièrement à jour leurs logiciels et applications système pour éviter l’exploitation secondaire des vulnérabilités.
Types d'attaques XSS
Selon l'OWASP (Open Web Application Security Project), les attaques XSS appartiennent à l'une des trois catégories suivantes : XSS reflété, XSS stocké et XSS Document Object Model (DOM). Ils sont détaillés ci-dessous.
Attaque de script intersite réfléchie (non persistante)
Une attaque XSS réfléchie se produit lorsqu'un pirate informatique livre un script malveillant à une application Web vulnérable, que le serveur renvoie ensuite dans la réponse HTTP. Le navigateur de la victime exécute le script malveillant dans le cadre de la réponse HTTP, compromettant l’utilisateur légitime et envoyant des informations privées au pirate.
Les attaques XSS réfléchies ciblent généralement les messages d'erreur ou les pages de résultats du moteur de recherche, car il est facile d'envoyer un e-mail malveillant avec un lien sur lequel de nombreux utilisateurs cliqueront. Lorsque l'utilisateur clique sur le lien, le serveur reçoit la demande contenant le script malveillant, et comme il n'est pas stocké, il répond en renvoyant un code à l'utilisateur. Lorsque les entrées des utilisateurs ne sont pas correctement validées et désinfectées, ou lorsque les données sont dupliquées de manière dangereuse à partir d’une demande, il existe un risque de vulnérabilités XSS reflétées.
La première ligne de défense contre les attaques XSS consiste à filtrer le contenu et à vérifier les entrées des utilisateurs. Vous pouvez utiliser les listes de sécurité et les listes de blocage des fournisseurs de script pour rejeter les modèles de données à risque.
De plus, vous pouvez mettre en œuvre une politique de sécurité du contenu (CSP) stricte pour vous aider à identifier la source des scripts en ligne, réduisant ainsi le risque d'attaques XSS réfléchies. Un CSP robuste vous permet de contrôler les scripts et les emplacements des pages Web où ils peuvent être chargés et exécutés.
Attaque de script intersite stockée (persistante)
Dans une attaque XSS stockée, un script malveillant enregistre l'entrée de l'utilisateur sur le serveur cible. Contrairement à une attaque XSS réfléchie, qui s'exécute sur le serveur, une attaque XSS stockée s'exécute sur le navigateur de l'utilisateur. Les attaquants utilisent ensuite des applications HTML5 modernes, qui utilisent généralement des bases de données HTML, pour stocker de manière permanente des scripts nuisibles sur le navigateur.
Dans une attaque XSS stockée, le script est enregistré et exécuté sur le serveur chaque fois que l'utilisateur accède au site Web concerné. Il est facile pour un attaquant de cibler un grand nombre de victimes, et le résultat est persistant. Les attaques XSS stockées peuvent également se produire lorsque des utilisateurs non formés essaient d'extraire des données du logiciel sans prendre de précautions de désinfection ou de validation.
Les attaques XSS stockées visent à refléter un script malveillant pour un utilisateur. Le moyen le plus simple de les empêcher est donc de désinfecter les données utilisateur et de gérer les entrées avec précaution. Le meilleur moyen de les empêcher est d'utiliser une liaison de paramètres appropriée.
Vous pouvez désinfecter les données à l'aide d'un système de modèle échappant automatiquement ou d'un codage HTML. Vous devez coder les données destinées à la sortie pour empêcher le serveur de les interpréter comme du contenu actif. Cela signifie que l'application traitera les caractères spéciaux dans ses données enregistrées en tant que contenu de balise HTML, plutôt qu'en HTML brut.
La liaison des paramètres de données (données) varie selon le vecteur, mais vous pouvez toujours transmettre des variables en tant que valeurs supplémentaires en dehors de la fonctionnalité normale de la fonction. Vous pouvez également utiliser des en-têtes de réponse appropriés pour prévenir les attaques, généralement en ajoutant simplement quelques lignes de code.
Une autre technique pour empêcher les attaques XSS de se produire en temps réel consiste à utiliser une sécurité dynamique qui recherche activement les tentatives d'exploitation. En bloquant les schémas connus, vous pouvez empêcher les attaquants d'exploiter les failles existantes.
Enfin, vous pouvez utiliser des pare-feu d'application Web (WAF) pour la détection et l'atténuation des attaques XSS en temps réel.
Attaque de script intersite Document Object Model (DOM)
L'interface DOM permet le traitement et la manipulation du contenu des pages Web en lisant et en modifiant les documents HTML et XML. Les attaques XSS basées sur DOM introduisent des modifications malveillantes dans le contexte DOM du navigateur de la victime, ce qui entraîne l'exécution involontaire du code côté client.
Les attaques XSS basées sur DOM, contrairement aux attaques XSS reflétées et stockées, ne stockent pas le script malveillant et ne le livrent pas au serveur. Dans cette attaque, le navigateur de la victime est la seule vulnérabilité. Étant donné qu’elles sont plus difficiles à comprendre que d’autres catégories, les vulnérabilités basées sur les DOM sont rares, sophistiquées et difficiles à surmonter. De plus, les scanners de vulnérabilité automatisés et les pare-feu d'applications Web ne peuvent pas les identifier facilement.
Vous pouvez utiliser les mêmes techniques pour éviter cette attaque que celles des deux autres, mais vous devez faire particulièrement attention à désinfecter le code côté client. Deux solutions efficaces consistent à empêcher les sources contrôlées par l’utilisateur de modifier les fonctions JavaScript potentiellement dangereuses (appelées « sinks ») ou à autoriser uniquement un contenu fiable en utilisant une liste sécurisée. Avec ces précautions, les chaînes qui pourraient mettre en danger le DOM ne seront pas envoyées dans les puits. Vous pouvez également désinfecter les données à l’aide de la fonctionnalité de navigateur intégrée, réduisant ainsi le risque de problèmes liés aux modifications de l’analyseur.
Une nouvelle défense contre ce type d'attaque consiste à utiliser des types fiables. Il s’agit d’un mécanisme de sécurité du navigateur qui garantit que toutes les parties risquées du DOM ne peuvent être utilisées que par des données qui ont passé une politique prédéfinie. Il empêche les chaînes arbitraires d'être transmises à des puits potentiellement dangereux, ce qui aide le navigateur à différencier le code des données, éliminant ainsi la principale source de vulnérabilité.
XSS côté serveur contre XSS côté client
Les attaques XSS sont classées en XSS serveur ou XSS client. Les programmes côté client s’exécutent sur l’appareil ou le navigateur du client et s’occupent de l’interface utilisateur et de tout autre traitement qui a lieu sur l’appareil du client. Les programmes côté serveur fonctionnent sur les serveurs et créent le contenu d'une page Web.
Le XSS côté serveur se produit lorsque tout le code côté serveur est vulnérable et que le navigateur rend la réponse et exécute tous les scripts légitimes qui y sont intégrés. D'autre part, le XSS côté client s'exécute sur l'appareil de l'utilisateur et modifie une page Web après son chargement.
Une attaque XSS est possible partout où il y a du HTML. Qu'elles soient stockées, réfléchies ou basées sur DOM, toutes les attaques XSS ont le même effet : Un attaquant prend le contrôle total d'une session Web.
Ces attaques XSS peuvent également se chevaucher, et un site Web peut être vulnérable aux trois simultanément. Dans le cas d'un seul site Web ou d'une application hors ligne, les trois types d'attaque peuvent se présenter directement dans le navigateur. Cependant, leur comportement peut différer lorsque les données sont enregistrées sur le serveur par rapport à lorsqu’elles sont reflétées par le serveur.
Comment les cyberattaques évoluent en 2025
Les cyberattaques deviennent plus vastes, plus complexes et plus impactantes. Qu’il s’agisse de ransomware, de phishing, d’attaques sur la chaîne d’approvisionnement ou d’exploits alimentés par l’IA, les attaquants innovent constamment pour contourner les défenses et exploiter les failles. Comprendre ces évolutions est essentiel pour renforcer la résilience numérique.
Rapport sur les risques cybernétiques 2025
Le dernier rapport de Trend Micro propose une analyse approfondie du paysage des menaces, avec des informations sur les vecteurs d’attaque émergents, les tendances en matière de risques et des recommandations stratégiques. Une ressource incontournable pour anticiper les prochaines cyberattaques.
Se défendre contre les cyberattaques avec Trend Micro
Comprendre ce qu’est une cyberattaque – qu’il s’agisse de ransomware, de phishing ou d’exploitation de la chaîne d’approvisionnement – n’est que la première étape. La suivante consiste à élaborer une stratégie de défense proactive capable de s’adapter aux menaces évolutives et de protéger votre organisation à travers les points de terminaison, les réseaux, les environnements cloud et les systèmes de messagerie.
La plateforme de cybersécurité d’entreprise de Trend Micro, Trend Vision One, offre une protection complète alimentée par l’IA, la détection et la réponse étendues (XDR), ainsi que la gestion de l’exposition aux risques cyber. Elle permet aux équipes de sécurité de détecter, d’enquêter et de répondre plus rapidement et efficacement aux menaces, transformant la visibilité en action et le risque en résilience.
Jon Clay travaille dans le domaine de la cybersécurité depuis plus de 29 ans. Jon utilise son expérience du secteur pour former et partager des informations sur toutes les recherches et informations sur les menaces publiées en externe par Trend Micro.