Le Cross-Site Scripting (XSS) est une cyberattaque dans laquelle un pirate insère un code malveillant dans un formulaire Web ou l’URL d’une application Web. Ce code malveillant, écrit dans un langage de script comme JavaScript ou PHP, peut faire n’importe quoi, de la destruction de la page que vous essayez de charger au vol de vos mots de passe ou d’autres identifiants de connexion.

XSS utilise un aspect important de l’Internet moderne, à savoir le fait que la plupart des pages Web sont créées pendant le chargement des pages, parfois en exécutant du code dans le navigateur lui-même. Cela peut rendre difficile la prévention de telles attaques.

Vérifiez également :

Comment fonctionne une attaque XSS ?

N’importe qui peut créer un site Web contenant du code malveillant. Dans le cas d’une attaque par cross-site scripting, l’attaquant s’arrange pour que son code atteigne l’ordinateur de la victime lorsqu’il visite le site Web d’un tiers. C’est de là que vient la « croix » dans le nom. Les attaques XSS y parviennent sans nécessiter d’accès privilégié à un serveur Web pour y placer subrepticement du code. Au lieu de cela, les attaquants profitent du fonctionnement des sites Web modernes.

Si quelqu’un vous demandait une explication simple et basique du fonctionnement du Web, vous pourriez probablement lui dire quelque chose comme ceci : la personne qui veut créer une page Web écrit un document HTML et le place sur un serveur Web ; Lorsque l’utilisateur veut accéder à cette page, il dirige son navigateur vers l’adresse du serveur, le navigateur télécharge et interprète le code HTML, et construit une copie de la page Web de l’utilisateur.

Cette description n’est pas fausse, mais certains aspects sont dépassés (et existent depuis plus de dix ans). Premièrement, de nombreuses pages Web, sinon toutes, sont dynamiques aujourd’hui – c’est-à-dire qu’elles n’affichent pas le même code HTML statique pour chaque visiteur, mais sont plutôt générées instantanément à partir des informations de la base de données du serveur lorsque le navigateur demande l’accès. La page que le navigateur reçoit du serveur dépend souvent des informations envoyées avec la requête – informations qui prennent parfois la forme de paramètres dans l’URL utilisée pour accéder au site. Les sites Web se composent non seulement de HTML et de feuilles de style en cascade (CSS) qui décrivent comment afficher du texte et des graphiques, mais ils contiennent également du code exécutable écrit dans des langages de script, généralement JavaScript.

Dans une attaque XSS, le pirate utilise cette interaction entre l’utilisateur et le site Web pour exécuter un code malveillant sur l’ordinateur de l’utilisateur. mais comment? Considérez l’URL suivante :

https://www.google.com/search?q=OSC+en ligne

Entrez-le 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 est exactement la même que si vous aviez saisi « CSO Online » dans la barre de recherche de votre navigateur ou sur la page d’accueil de Google. Vous remarquerez, entre autres, que cette phrase apparaît à plusieurs endroits sur la page, dont la barre de recherche en montagne :

Et si, au lieu de l’expression innocente et réussie « OSC en ligne », cette URL contenait un code JavaScript malveillant comme celui-ci ?

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

doEvil() fait un très mauvais travail ici. Vous craignez peut-être que Google, au lieu d’afficher « CSO Online » sur la page que vous renvoyez à partir de cette URL, intègre dynamiquement le mauvais javascript dans la page que vous affichez, et que ce script soit exécuté dans votre navigateur , provoquant un gâchis . Vos inquiétudes seront sans fondement, car Google compte un très grand nombre de talentueux professionnels de la sécurité informatique parmi ses employés et a mis en place des mesures correctives dont nous parlerons un peu plus tard. Cependant, tous les sites ne sont pas très prudents et cela vous donne une idée du fonctionnement de telles attaques.

Ataki XSS

Les attaques XSS se répartissent 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éflexes : également appelées attaques faibles, le code JavaScript malveillant est envoyé du navigateur de la victime à Google, puis renvoyé sous une forme exécutable, jamais stocké sur les serveurs de Google. Ces attaques font souvent partie d’une escroquerie par hameçonnage, où le lien malveillant est déguisé en quelque chose de plus amusant et envoyé à la victime par e-mail ou SMS.
• Attaques basées sur DOM : il s’agit d’un type d’attaque réflexe appelé Document Object Model, qui est une API standard qui définit la façon dont les navigateurs créent une page Web à partir de code HTML ou JavaScript de base. La plupart des attaques DOM sont similaires à l’attaque réflexe décrite précédemment, à la différence que le code malveillant n’est jamais envoyé au serveur : à la place, il est passé en paramètre à une fonction JavaScript qui est exécutée dans le navigateur lui-même, ce qui signifie que les mécanismes protégeant côté serveur sont incapables de protéger l’utilisateur. Si vous êtes intéressé par les détails, PortSwigger a une description plus détaillée du fonctionnement des attaques DOM.
• Attaques stockées : autrement persistantes ; L’attaquant utilise les fonctionnalités interactives du site Web pour enregistrer un code malveillant sur le serveur Web. Dans un exemple typique, l’attaquant laisse un commentaire sur un article de blog contenant du JavaScript malveillant. La prochaine fois que quelqu’un chargera cette page, le code sera exécuté.
• Vulnérabilité à l’attaque XSS

Qu’est-ce qui rend un site Web vulnérable à une attaque XSS ? J’espère que notre discussion jusqu’à présent a fourni des indications. Si votre application Web accepte naïvement les entrées de l’utilisateur, ne vérifie pas qu’il n’y a pas de code exécutable malveillant et utilise ces données pour afficher une page ou effectuer d’autres opérations, elle est vulnérable à ce type d’attaque.

Et les risques sont grands. Le principal aspect de la sécurité du navigateur est la politique dite de même origine, qui stipule qu’un script s’exécutant sur une page ne peut accéder aux données de l’autre page que si les deux côtés ont la même origine (définie comme une combinaison d’URI, de nom d’hôte, et numéro de port). Cependant, si du JavaScript malveillant peut être exécuté dans le navigateur pendant que la victime accède au site Web, le navigateur permettra au JavaScript d’accéder aux données d’autres sites Web qui partagent une ressource avec le site Web vulnérable. JavaScript peut accéder aux cookies et à d’autres informations de session propriétaires, ce qui est une bonne recette pour pirater les comptes Internet des victimes.

Charges utiles XSS

Dans le jargon des logiciels malveillants, une charge utile est un code exécutable qui exécute les actions requises par l’attaquant. Dans le cas d’une attaque XSS, la charge utile est un code de script que l’attaquant exécute pour inciter le navigateur de la victime à s’exécuter.

Il existe une énorme liste de modèles de charge utile XSS dans le référentiel Payloadbox sur GitHub. Si vous êtes familier avec JavaScript, l’examiner pourrait vous donner une idée de la façon dont les attaquants XSS font leur sale boulot. Cependant, une attaque XSS va au-delà du copier-coller de la charge utile dans l’URL : l’attaquant doit comprendre les fonctions et les vulnérabilités spécifiques de l’application Web qu’il souhaite exploiter pour planifier l’attaque. Si vous souhaitez approfondir et voir quelques exemples d’attaques XSS, consultez le site Web OWASP XSS pour un examen approfondi du code de script qui illustre une attaque XSS.

Protection et prévention XSS

Si vous créez ou gérez une application Web ou un site Web interactif, vous devez prendre en compte trois techniques principales dans votre conception pour éviter les attaques potentielles de script intersite.

• Stérilisation des données d’entrée. La réponse évidente pour empêcher qu’un code malveillant soit transmis en entrée et renvoyé à l’utilisateur consiste simplement à ne pas accepter de code de script en entrée. Vous devriez certainement filtrer votre entrée en gardant cela à l’esprit, mais c’est plus facile à dire qu’à faire ; De petits morceaux de code exécutable peuvent passer à travers les filtres. Une façon de traiter ce problème est d’utiliser une approche de liste blanche au lieu d’une approche de liste noire – par exemple, au lieu d’essayer d’écrire un filtre qui bloquera tout code malveillant introduit dans un formulaire Web, vous devez écrire votre application pour accepter le données à certains moments Formats (numéros de téléphone, adresses e-mail, etc.) uniquement lorsque c’est ce que vous voulez.
• Échappez-vous de la sortie. C’est la solution au problème d’autre part. Si une application Web renvoie une entrée utilisateur vers une page Web, ces données doivent être filtrées pour s’assurer qu’elles ne deviennent pas exécutables sur cette page. Si l’utilisateur entre des balises HTML en entrée, l’application doit utiliser des caractères remplacés afin que ces balises apparaissent sous forme de texte sur la page de résultats plutôt que de s’intégrer au code HTML de la page elle-même.
• Politique de sécurité de contenu standard (CSP). CSP adopte l’approche de « liste blanche » en dehors de la saisie de texte dans le domaine des scripts : une application Web ne doit exécuter que le code que l’utilisateur a spécifié comme étant sûr. Google propose d’excellentes ressources sur la mise en œuvre de CSP.

Test XSS

Les tests de vulnérabilité pour les attaques XSS sont un aspect important pour garantir la sécurité d’une application Web. L’OWASP dispose de ressources détaillant comment les applications peuvent être testées pour éviter les attaques DOM ou les scripts intersites inversés. Si vous recherchez une feuille XSS, l’OWASP a également un document avec le code d’attaque XSS qui peut être utilisé pour contourner certains filtres de défense XSS ; Il s’avérera inestimable dans les tests d’intrusion que vous pourrez effectuer sur vos propres systèmes.

XSS à CSRF

Vous pouvez entendre que CSRF est utilisé dans le même contexte que XSS. C’est l’abréviation de Cross-Site Request Forgery, une attaque – comme XSS – qui cible le navigateur d’un utilisateur. La principale différence est que CSRF utilise une session authentifiée pour l’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 qu’un utilisateur soit connecté à Twitter et à une banque Internet en même temps, et qu’il clique sur un lien Twitter qui ressemble à ceci :

http://www.votrebanque.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, ils peuvent soudainement devenir beaucoup plus pauvres. 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 préparé une fiche d’information sur les mesures de protection contre le CSRF.

Attaques XSS récentes et infâmes

L’une des attaques de scripts intersites les plus anciennes et les plus célèbres s’est produite en 2005, lorsque l’utilisateur entreprenant de MySpace, Sammy Kamkar, s’est rendu compte qu’il pouvait entrer du code JavaScript dans son profil qui authentifierait automatiquement toute personne visitant le site – et également copier ce code dans les profils de votre de nouveaux amis, grâce à cela, tous ceux qui visitent ces pages seront aussi son ami. (Le script a fait en sorte que chacun des nouveaux amis de Kamkar se classe dans le « top huit » – nous avons peur de comprendre cela, vous devriez être là, mais croyez-nous, c’était important.) En 24 heures, il s’est fait plus d’un million d’amis et a forcé MySpace à fermer l’ensemble du site pendant une courte période.

Il s’avère que le soi-disant ver Sami est pour la plupart inoffensif. Cependant, d’autres étaient plus ennuyeux:

• Ebay a eu des vulnérabilités XSS pendant des années qui ont permis aux pirates de voler les identifiants de connexion des utilisateurs

• Les attaquants XSS ont pu voler des V-Bucks aux joueurs de Fortnite en 2019.

• Le groupe de piratage Magecart a attaqué British Airways en 2018 avec une attaque XSS, volant des centaines de milliers d’identités d’utilisateurs

Et les scripts intersites restent une menace sérieuse aujourd’hui. Depuis 2021, des vulnérabilités XSS ont été découvertes dans la plateforme de messagerie Zimbra, Wordpress et la plateforme de gestion informatique open source Nagios. Gardez à l’esprit que les pirates n’utilisent généralement pas les techniques d’attaque de manière isolée : les scripts intersites sont un composant d’une forme complexe récemment découverte de l’attaque générique TLS connue sous le nom d’ALPACA. Pour éviter les menaces dangereuses, assurez-vous de fermer les vulnérabilités XSS.

Source : OSC