Aller au contenu
TortueTech
RubriquesRéférentiels & catalogues

CWE-79 : cross-site scripting, la classe au premier rang du Top 25

CWE-79 : cross-site scripting, la classe au premier rang du Top 25

Section intitulée « CWE-79 : cross-site scripting, la classe au premier rang du Top 25 »

Première du CWE Top 25 2025, et première d’à peu près toutes les éditions depuis que ce classement existe. Son libellé officiel est Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’), que l’on traduit par « neutralisation incorrecte des entrées lors de la génération d’une page web ». Le surnom entre guillemets, cross-site scripting, a tellement pris le dessus que plus personne ne cite le vrai nom : ce qui est dommage, car le vrai nom dit où est le défaut, et le surnom dit seulement ce qu’il permet.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Section intitulée « Ce que la classe recouvre exactement »

La définition du MITRE tient en une phrase : le produit ne neutralise pas, ou neutralise incorrectement, une entrée contrôlable par l’utilisateur avant de la placer dans une sortie servie comme page web à d’autres utilisateurs. Chaque morceau de cette phrase compte.

« Ne neutralise pas ou neutralise incorrectement » : la classe ne distingue pas l’absence d’échappement de l’échappement raté. Une application qui filtre consciencieusement <script> mais laisse passer onerror= relève exactement de la même entrée que celle qui ne filtre rien.

« Avant de la placer dans une sortie » : le défaut est à l’écriture de la page, pas à la lecture du formulaire. C’est le contresens le plus coûteux du domaine : on croit corriger un XSS en validant l’entrée, alors que la correction tient à l’échappement au moment de l’écriture, et dépend du contexte où la donnée atterrit : corps HTML, valeur d’attribut, code JavaScript, feuille de style, adresse d’URL. Cinq contextes, cinq échappements différents.

« Servie à d’autres utilisateurs » : c’est ce qui fait du XSS une attaque et non une bizarrerie. Du code injecté dans sa propre page ne lèse personne ; le même code servi au navigateur d’un administrateur authentifié agit avec ses droits.

Le catalogue reconnaît explicitement les trois familles usuelles comme termes alternatifs de la même entrée (XSS réfléchi (type 1), stocké (type 2) et fondé sur le DOM (type 0)) ainsi que l’appellation « injection HTML ». Autrement dit, elles ne portent pas de numéro distinct : un rapport qui écrit « CWE-79 » ne dit pas laquelle des trois il a trouvée, et c’est une information qu’il faut aller chercher ailleurs.

Sa place dans l’arbre

Section intitulée « Sa place dans l’arbre »

CWE-79 est une base, c’est-à-dire le niveau assez précis pour qu’on sache quoi corriger. Son parent est la classe CWE-74, « neutralisation incorrecte d’éléments spéciaux dans une sortie utilisée par un composant en aval », qui est le tronc commun de toutes les injections : l’injection SQL, l’injection de commande et le XSS sont trois branches d’un même mécanisme, une donnée franchit une frontière de langage sans être requalifiée.

En dessous, sept variantes descendent dans le détail du contournement : balises de script non neutralisées (CWE-80), script dans une page d’erreur (CWE-81), script dans un attribut (CWE-83), schéma d’URI encodé (CWE-84), caractères doublés (CWE-85), caractères invalides dans un identifiant (CWE-86), syntaxe XSS alternative (CWE-87). On les rencontre rarement dans les rapports, parce que les scanners s’arrêtent au niveau de la base.

Le catalogue note enfin une parenté intéressante avec CWE-352, la falsification de requête inter-sites : ce sont des pairs, pas des parents. Les deux exploitent la confiance du navigateur, mais le XSS fait exécuter du code dans la page, là où le CSRF fait émettre une requête légitime. Un XSS contourne d’ailleurs la plupart des protections anti-CSRF, puisqu’il permet de lire le jeton avant de l’utiliser.

Pourquoi elle est première

Section intitulée « Pourquoi elle est première »

Trois raisons, dont aucune n’est « c’est la plus grave ».

Elle se détecte très bien. Un scanner d’application web envoie une charge d’essai inoffensive, relit la page produite, et constate si sa chaîne ressort échappée ou non. Le verdict est binaire, reproductible, automatisable. Les faiblesses qui se mesurent aussi facilement remontent mécaniquement dans un classement construit sur les vulnérabilités publiées.

Elle est partout où il y a du HTML. Toute application qui affiche une donnée venue d’ailleurs est concernée, soit l’intégralité du web applicatif, des interfaces d’administration d’imprimantes aux portails bancaires. La surface est donc colossale, et les produits de niche (plateformes de gestion, greffons de systèmes de publication, appareils à interface web) fournissent chaque année plusieurs milliers de vulnérabilités de ce type.

Elle résiste aux corrections ponctuelles. Un XSS corrigé à un endroit laisse les quarante autres points d’affichage de la même application, et les frameworks modernes qui échappent par défaut sont régulièrement contournés par un dangerouslySetInnerHTML, un v-html ou l’équivalent, écrit de bonne foi par quelqu’un qui voulait afficher du gras.

Le mécanisme, et où le site le traite

Section intitulée « Le mécanisme, et où le site le traite »

Le fonctionnement détaillé (les trois variantes, la différence entre échappement et assainissement, le rôle d’une politique de sécurité de contenu et les défenses qui tiennent vraiment) est traité dans la page cross-site scripting : mécanisme, variantes et défenses, qu’il est inutile de résumer ici.

Deux renvois complètent le tableau : la politique de même origine explique ce que le navigateur cloisonne, et donc ce qu’un script injecté obtient exactement quand il s’exécute dans la bonne origine ; les attributs du cookie de session décrivent HttpOnly, qui ne corrige aucun XSS mais retire au script injecté l’accès au cookie, ce qui change la portée du dégât.

Côté classement, le XSS occupe aussi la catégorie A03 du Top 10 web de l’OWASP, où il a été fusionné avec les autres injections depuis l’édition 2021 : la même faiblesse, lue par un autre catalogue, change de code et de voisinage.

Ce qu’une équipe en fait

Section intitulée « Ce qu’une équipe en fait »

Trois gestes, dans cet ordre de rendement décroissant.

Échapper à la sortie, par défaut, dans le moteur de rendu : c’est le seul contrôle qui couvre les points d’affichage qu’on n’a pas inventoriés. Les contournements explicites de l’échappement deviennent alors une liste finie, auditable, à justifier un par un en revue.

Assainir le HTML riche avec une bibliothèque maintenue, quand l’application doit vraiment accepter de la mise en forme. Une liste blanche écrite à la main par l’équipe est systématiquement contournée, et l’absence d’échappement contextuel est précisément ce qu’une revue de code doit chercher.

Poser une politique de sécurité de contenu, qui ne corrige rien mais réduit ce qu’un script injecté peut faire, et dont les rapports de violation signalent les injections en production : y compris celles que le scanner n’a pas trouvées.

Sources

Section intitulée « Sources »

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Une équipe qui ignore la classe corrige des symptômes : le champ « nom » du formulaire d’inscription est échappé parce qu’un rapport l’a signalé, le champ « commentaire » ne l’est pas parce que personne ne l’a testé. L’application accumule alors des points d’affichage sains et malsains sans qu’aucun inventaire n’existe, et la revue de code passe à côté, faute de savoir que le défaut se juge au contexte d’écriture et non à la provenance de la donnée. Le coût se révèle le jour où le script injecté dans un champ oublié est servi à la session d’un administrateur : l’attaquant n’a plus besoin de voler un mot de passe, il agit dans le navigateur de quelqu’un qui a déjà tous les droits, et les journaux du serveur ne montrent que des requêtes parfaitement authentifiées.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Une page web est un texte que le navigateur lit et met en forme. Dans ce texte, certains signes ne sont pas du contenu mais des instructions : ils disent « ce qui suit est un titre », « ce qui suit est un programme à exécuter ». Le navigateur obéit à ces instructions sans se demander qui les a écrites.

Beaucoup de pages contiennent des informations venues des visiteurs : un pseudonyme, un commentaire, le nom d’un fichier. Si le site recopie ces informations dans la page sans précaution, un visiteur malveillant peut y glisser non pas du texte, mais des instructions. Le navigateur du visiteur suivant les exécutera, croyant qu’elles viennent du site.

C’est ce défaut que le catalogue CWE appelle CWE-79, surnommé « cross-site scripting ». Son nom officiel est plus parlant : « neutralisation incorrecte des entrées lors de la génération d’une page web ». La neutralisation consiste à transformer les signes d’instruction en signes de texte ordinaire, de sorte que le navigateur les affiche au lieu de les suivre.

Deux points surprennent souvent. D’abord, la réparation ne se fait pas à l’endroit où le site reçoit l’information, mais à l’endroit où il l’écrit dans la page : la même donnée doit être transformée différemment selon l’endroit où elle atterrit. Ensuite, la victime n’est pas celui qui a écrit le texte piégé, mais celui qui consulte la page ensuite : et plus cette personne a de droits sur le site, plus le dégât est grand. C’est pourquoi ce défaut, jugé bénin par ceux qui ne l’ont jamais vu exploité, occupe la première place du classement annuel depuis des années.

À lire aussi

Pages voisines

La citent

CWE-79 : cross-site scripting, la classe au premier rang du Top 25

Elle cite

: les deux pages se citent l’une l’autre.