Qu’est-ce que XSS ? Les attaques de script intersite expliquées

Le cross-site scripting (XSS) est une cyberattaque dans laquelle un pirate saisit un code malveillant dans un formulaire Web ou une URL d’application Web. Ce code malveillant, écrit dans un langage de script comme JavaScript ou PHP, peut faire n’importe quoi, du vandalisme du site Web que vous essayez de charger au vol de vos mots de passe ou d’autres identifiants de connexion.

XSS tire parti d’un aspect important du Web moderne, à savoir que la plupart des sites Web sont créés à la volée lors du chargement des pages, parfois en exécutant du code dans le navigateur lui-même. Cela peut rendre de telles attaques difficiles à prévenir

Comment fonctionne XSS

N’importe qui peut créer un site Web contenant du code malveillant. Dans une attaque de script intersite, un attaquant configure les choses pour que son code se retrouve sur l’ordinateur de sa victime lorsque celle-ci accède quelqu’un d’autre’le site Web. C’est de là que vient la “croix” dans le nom. Les attaques XSS parviennent à y parvenir sans avoir besoin d’obtenir un accès privilégié au serveur Web pour y implanter du code subrepticement. Au lieu de cela, les attaquants profitent du fonctionnement des pages Web modernes.

Si quelqu’un vous demandait une explication de base du Web, vous lui diriez probablement quelque chose comme ceci : une personne qui souhaite créer une page Web écrit un document HTML qu’elle télécharge sur un serveur Web ; lorsqu’un utilisateur souhaite accéder à cette page, il pointe son navigateur vers l’adresse du serveur, et le navigateur télécharge le code HTML et l’interprète pour créer une version de la page Web pour l’utilisateur.

Cette description n’est pas exactement fausse, mais certains aspects sont obsolètes (et le sont depuis une décennie ou plus). Tout d’abord, de nombreuses pages Web, sinon toutes, sont désormais dynamiques, c’est-à-dire qu’elles n’affichent pas le même code HTML statique pour chaque visiteur, mais sont plutôt construites à la volée à partir des informations contenues dans la base de données du serveur lorsqu’un navigateur demande l’accès. . La page que le navigateur récupère du serveur dépend souvent des informations qu’il envoie avec sa requête, des informations qui prennent parfois la forme de paramètres dans l’URL utilisée pour accéder au site. Et les sites Web ne consistent pas seulement en HTML et en feuilles de style en cascade (CSS) qui décrivent comment le texte et les graphiques doivent être rendus ; ils incluent également du code exécutable écrit dans des langages de script, généralement JavaScript. Mélanger les données, la présentation et le code exécutable de cette manière est une sorte de “péché originel” de la sécurité Web.

Dans une attaque XSS, un pirate profite de cette interaction entre un utilisateur et un site Web pour faire exécuter un code malveillant sur la machine de l’utilisateur. Mais comment? Considérez l’URL suivante :

https://www.google.com/search?q=CSO+online

Mettez cela dans la barre d’adresse de votre navigateur et vous verrez les résultats de recherche Google pour “CSO Online”. En fait, la page que vous verrez apparaît exactement comme si vous aviez tapé “CSO en ligne” dans la barre de recherche de votre navigateur ou sur la page d’accueil de Google.com. Entre autres choses, vous remarquerez que la phrase apparaît à plusieurs endroits sur la page, notamment dans la barre de recherche en haut :

OSC

Maintenant, que se passerait-il si au lieu de l’expression innocente et saine “OSC en ligne”, cette URL contenait un code JavaScript malveillant, comme celui-ci ?

https://www.google.com/search?<script>doEvil()</script>

doEvil() remplace ici une fonctionnalité vraiment désagréable. Vous craignez peut-être que Google, au lieu d’afficher “CSO Online” sur la page qu’il renvoie à partir de cette URL, incorpore à la place ce mauvais JavaScript dans la page Web qu’il rend dynamiquement, et que ce script s’exécute alors dans le navigateur, faisant des ravages. Votre inquiétude serait infondée, car Google compte parmi son personnel de nombreux professionnels de la sécurité informatique talentueux et a mis en place des mesures d’atténuation du type de celles dont nous parlerons dans un instant. Mais tous les sites ne sont pas aussi prudents, et cela vous donne une idée de la façon dont ces attaques peuvent fonctionner.

Attaques XSS

Les attaques XSS sont divisées en plusieurs catégories : les attaques réfléchies, les attaques basées sur DOM et les attaques stockées. Voici comment ils diffèrent :

Attaques réfléchies : L’attaque décrite ci-dessus serait appelée une reflété ou non persistante attaque, car le code JavaScript malveillant a été envoyé du navigateur Web de la victime à Google, puis renvoyé sous une forme exécutable, et n’est jamais stocké de manière persistante sur les serveurs de Google. Ces attaques font souvent partie d’un Hameçonnage arnaque, où le lien maléfique est déguisé en quelque chose de plus acceptable et envoyé à la victime par e-mail ou SMS.

Attaques basées sur DOM : Il s’agit d’une variante de l’attaque réfléchie et porte le nom du modèle d’objet de document, une API standardisée qui définit la manière dont les navigateurs créent une page Web à partir de code HTML ou JavaScript sous-jacent. La plupart des attaques basées sur DOM sont similaires à l’attaque réfléchie que nous venons de décrire, sauf que le code malveillant n’est jamais envoyé au serveur : à la place, il est passé en paramètre à une fonction JavaScript qui s’exécute dans le navigateur lui-même, ce qui signifie que le serveur- les défenses latérales ne peuvent pas protéger l’utilisateur. PortSwigger a un examen plus approfondi du fonctionnement des attaques basées sur DOM si vous êtes intéressé par les détails.

Attaques stockées : Le dernier type principal d’attaque XSS est un stockée ou persistant attaque, et c’est un peu plus simple, mais aussi assez dangereux. Dans une attaque stockée, l’attaquant parvient à utiliser les fonctionnalités interactives d’un site pour stocker du code malveillant sur le serveur Web. Dans un exemple courant, un attaquant laisserait un commentaire sur un article de blog contenant du JavaScript malveillant. La prochaine fois que quelqu’un chargera cette page, le code s’exécutera.

Vulnérabilité XSS

Qu’est-ce qui rend un site Web vulnérable à une attaque XSS ? J’espère que notre discussion jusqu’à présent vous a donné un indice. Si votre application Web accepte naïvement l’entrée de l’utilisateur, ne la recherche pas de code exécutable potentiellement malveillant et utilise cette entrée pour afficher une page Web ou effectuer d’autres opérations, elle est vulnérable à ce type d’attaque.

Et les enjeux sont élevés. Un aspect crucial de la sécurité du navigateur est ce que l’on appelle le politique de même origine, qui dicte qu’un script s’exécutant sur une page ne peut accéder aux données d’une deuxième page que si les deux pages partagent un origine (défini comme la combinaison d’un schéma d’URI, d’un nom d’hôte et d’un numéro de port). Mais si du JavaScript malveillant peut s’exécuter dans le navigateur pendant que la victime accède à un site Web, le navigateur permettra à ce JavaScript d’accéder aux données d’autres pages qui partagent une origine avec la page vulnérable. Que JavaScript peut accéder aux cookies et autres informations de session restreintece qui constitue une bonne recette pour s’introduire dans les comptes en ligne des victimes.

Charges utiles XSS

Dans malware jargon, un charge utile est un code exécutable qui effectue les actions que l’attaquant souhaite effectuer. Dans une attaque XSS, la charge utile est le code de script que l’attaquant parvient à inciter le navigateur de la victime à s’exécuter.

Le référentiel payloadbox sur GitHub contient une énorme liste de exemples de charges utiles XSS. Si vous connaissez JavaScript, les examiner peut vous donner une idée de la façon dont les attaquants XSS font leur sale boulot. Cependant, une attaque XSS va bien au-delà du copier-coller d’une charge utile dans une URL : l’attaquant doit comprendre les fonctionnalités et les vulnérabilités spécifiques de l’application Web qu’il tente de compromettre afin de planifier son assaut. Si vous voulez aller plus loin et voir quelques Exemples d’attaques XSS, consultez l’OWASP Page XSSqui approfondit le code de script illustrant une attaque XSS.

Protection et prévention XSS

Si vous créez ou exploitez une application Web ou un site Web interactif, vous devez intégrer trois techniques principales dans la conception pour atténuer les attaques potentielles de script intersite.

• Assainissement des entrées. La réponse évidente pour empêcher le code de script malveillant d’être transmis en tant qu’entrée et renvoyé à l’utilisateur est tout simplement de ne pas accepter le code de script en tant qu’entrée en premier lieu. Vous devriez certainement filtrer les entrées en gardant cela à l’esprit, mais c’est plus facile à dire qu’à faire ; des extraits intelligemment conçus de code exécutable peuvent être glissés à travers des filtres. Une façon de gérer cela est d’adopter une approche de liste blanche plutôt que de liste noire. Par exemple, plutôt que d’essayer d’écrire un filtre qui empêche tout code malveillant d’être saisi dans un formulaire Web, écrivez votre application de sorte qu’elle n’accepte que les données dans formats spécifiés (numéros de téléphone, adresses e-mail, etc.) si c’est ce que vous attendez.
• Sortie s’échappant. Cela aborde le problème dans l’autre sens. Si votre application Web renvoie des données saisies par l’utilisateur vers une page Web, ces données doivent être filtrées pour s’assurer qu’elles ne deviennent pas du code exécutable sur cette page Web. Si l’utilisateur entre le code des balises HTML en entrée, votre application doit utiliser caractères d’échappement pour s’assurer que ces balises apparaissent sous forme de texte sur la page résultante, plutôt que d’être intégrées dans la page HTML elle-même.
• La norme de politique de sécurité du contenu (CSP). CSP adopte l’approche de la liste blanche au-delà de la simple saisie de texte et dans le domaine de l’exécution de script : votre application Web ne doit jamais exécuter que le code spécifique que vous avez déclaré sûr. Google a quelques excellentes ressources sur la mise en œuvre du CSP.

Test XSS

Le test des vulnérabilités XSS est un aspect important de la sécurité de votre application Web. L’OWASP dispose de ressources qui approfondissent la façon dont vous pouvez tester la vulnérabilité de vos applications à basé sur DOM ou reflété attaques de script intersite. Si vous cherchez un Aide-mémoire XSS, OWASP vous a également couvert avec un document plein de code pour les attaques XSS qui peuvent être utilisées pour contourner certains filtres défensifs XSS; ceux-ci se révéleront inestimables pour tout tests de pénétration vous pourriez faire contre vos propres systèmes.

XSS contre CSRF

Vous pourriez entendre CSRF utilisé dans le même contexte que XSS. Cela signifie falsification de demande intersite, qui est une attaque qui, comme XSS, cible le navigateur d’un utilisateur. La principale différence est que CSRF exploite la session authentifiée d’un utilisateur (peut-être qu’il est connecté à son compte bancaire), tandis que XSS n’a pas besoin d’une session authentifiée pour être efficace.

Supposons que vous étiez connecté à Twitter et à la banque en ligne en même temps, et que vous avez cliqué sur un lien Twitter qui ressemblait à ceci :

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

Selon la façon dont votre banque gère les jetons de session et le navigateur que vous utilisez, vous pourriez être cinq mille plus pauvre. XSS est un vecteur d’attaque plus dangereux, mais il est important de se défendre à la fois contre XSS et CSRF. L’OWASP a une feuille de triche pour les mesures de sécurité défensives du CSRF ainsi que.

Attaques XSS récentes et célèbres

L’une des premières et des plus célèbres attaques de scripts intersites a eu lieu en 2005, lorsque l’utilisateur entreprenant de MySpace, Samy Kamkar, a compris qu’il pouvait insérer du code JavaScript dans son profil qui se lierait automatiquement d’amitié avec toute personne ayant visité la page—et également copier le code dans les profils de ses nouveaux amis, afin que tous ceux qui ont visité celles pages également ami avec lui. (Le script s’est assuré que chacun des nouveaux amis de Kamkar l’avait comme l’un de leur “Top 8”, quelque chose que nous avons peur que vous ayez vraiment dû être là à l’époque pour comprendre, mais faites-nous confiance quand nous disons que c’était important. ) En 24 heures, il s’est fait plus d’un million d’amis et a forcé MySpace à mettre brièvement tout son site hors ligne.

Le soi-disant ver Samy s’est avéré pour la plupart inoffensif. Mais d’autres étaient bien plus troublants :

Et les scripts intersites restent une menace majeure aujourd’hui. Depuis 2021, des vulnérabilités XSS ont été découvertes dans le Plateforme de messagerie Zimbra, WordPresset le Nagios plate-forme de gestion informatique open source. Et n’oubliez pas que les pirates n’utilisent généralement pas les techniques d’attaque de manière isolée : les scripts intersites sont l’un des composants d’une forme d’attaque complexe et récemment découverte utilisant des certificats TLS génériques appelés ALPAGA, par exemple. Vous devez vous assurer que vos vulnérabilités XSS sont fermées pour éviter les gros risques.

Copyright © 2022 IDG Communications, Inc.

— to www.csoonline.com