Cross-Site Scripting - Comment les pirates informatiques détournent votre site

Tobias Schüring Dernière mise à jour : 15.01.2020
6 Min.
Cross-Site Scripting_XSS

XSS, injection SQL, XMLrpc - lorsqu'une mise à jour de sécurité de WordPress est publiée, les rapports de mise à jour contiennent principalement des acronymes cryptiques. Même s'il est clair que ces mises à jour sont nécessaires et que le plus en matière de sécurité est très satisfaisant, il est important de comprendre ce qui se cache derrière ces vulnérabilités de sécurité. Car ce n'est que si vous comprenez quelles lacunes les mises à jour comblent que vous pouvez également prendre une décision éclairée. C'est pourquoi nous allons aujourd'hui nous pencher sur le cross-site scripting, ou XSS, qui est de loin l'attaque complexe la plus courante sur les pages WordPress .

Les attaques de pirates informatiques peuvent être comparées à des cambrioleurs. Brute Force Les attaques ressemblent davantage à la méthode du pied de biche. Le criminel résiste à l'outil jusqu'à ce que la porte ou la fenêtre s'ouvre. Les attaques contre les vulnérabilités XSS, d'autre part, sont sophistiquées : Le cambrioleur sait exactement par où commencer et obtient un accès ciblé à une page.

Dans le cadre de la rédaction de scripts intersites, les lacunes de sécurité des sites web sont délibérément exploitées. Les pirates informatiques injectent des scripts malveillants dans un contexte de confiance (vos pages !). Semblable à un passager clandestin sur un bateau, ce code malveillant utilise votre site comme un véhicule pour poursuivre ses propres objectifs.

Dans le pire des cas, les agresseurs obtiennent ainsi des informations confidentielles ou l'accès à l'ordinateur de l'utilisateur victime. De telles attaques ne sont pas vraiment rares : Une bonne moitié des vulnérabilités découvertes par le fournisseur de sécurité Wordfence en 2015 et 2016 étaient des vulnérabilités de type "cross-site scripting" dans Plugins .. Souvent, une attaque XSS constitue alors la "base" d'autres attaques, telles que le spam, le phishing ou les attaques DDoS. C'est pourquoi je vais vous montrer aujourd'hui comment fonctionne exactement le cross-site scripting, quels types d'attaques il y a et à quel point ces attaques sont dangereuses.

Les scripts intersites fonctionnent toujours de la même manière : un code malveillant s'introduit sur votre site par une brèche.

Le cross-site scripting est un danger lorsqu'une application web transmet des données utilisateur saisies au navigateur web sans vérifier le code du script. Un bon exemple d'une telle application web est un chat de soutien.

Via l'application web elle-même les scripts malveillants peuvent atteindre le serveur. À partir de là, le code malveillant finit tôt ou tard par retomber sur les clients concernés. Un bon exemple d'une telle vulnérabilité XSS est le bogue découvert en juillet 2016 dans les méta-infos d'images sur WooCommerce 2.6.2. Un bogue a permis aux attaquants d'injecter du code HTML dans les méta descriptions des images depuis l'extérieur. Tout client qui aurait regardé de plus près l'image en question (par exemple en cliquant sur l'image) courrait le risque d'être attaqué. Par exemple, un hacker pourrait avoir infecté les ordinateurs de vos clients avec un virus.

Astuce populaire pour les scripts intersites : les formulaires manipulés

Le XSS peut également permettre aux pirates de remplacer des formulaires inoffensifs par des formulaires manipulés. Ces formulaires permettent ensuite de recueillir les données des victimes (les visiteurs de votre site !). DD'ailleurs, même le cryptage SSL ne peut pas vous protéger contre cela. HTTPS "uniquement" signifie que la connexion entre le serveur et le client est cryptée. Cependant, si le formulaire lui-même a été manipulé, même une connexion cryptée est inutile.

Comme pour les autres types d'attaques, le but des pirates est le plus souvent de monétiser leurs machinations. Concrètement, cela signifie que les attaquants volent des données qu'ils vendent ensuite ou veulent infecter des sites afin de les intégrer dans un "botnet" qui est ensuite loué.

3 types de XSS : XSS réfléchi, persistant et local

Les attaques de scripting intersites peuvent être divisées en trois types :

En gros, les attaques XSS fonctionnent comme suit : Le code malveillant est injecté là où l'on s'attend à une intervention de l'utilisateur (par exemple, dans une recherche interne à la page). Dans le cadre de la réponse du serveur, le code malveillant est ensuite exécuté sur le client, c'est-à-dire dans le navigateur de l'utilisateur. Et c'est exactement là que le mal est fait, par exemple lorsque des données d'utilisateur sont volées.

Scénario intersites réfléchi

Certaines données, telles que les requêtes de recherche, sont prises en compte par le serveur. Cela signifie que, par exemple, après avoir entré "test" dans la boîte de recherche, la page retournera "vous avez cherché test". Ainsi, ce que l'utilisateur saisit devient une partie de la réponse du serveur.

C'est exactement ce que les attaquants exploitent intelligemment : Si un script malveillant est envoyé au serveur web au lieu d'un terme de recherche, la page peut être manipulée pour finalement l'exécuter. Ce type d'attaque est également connu sous le nom de non persistant dite non persistante. Le code malveillant n'est donc injecté que temporairement dans la page concernée, mais n'est pas stocké.

En juillet, une telle vulnérabilité a été trouvée dans Plugin WP Statistics (et corrigée le même jour !). Une valeur d'entrée sur la page "wps_visitors_page" a été transmise sans être vérifiée, ce qui a conduit à une vulnérabilité par le biais du XSS réfléchi. Ainsi, une page pourrait être piratée si un administrateur avait préalablement cliqué sur un lien manipulé de manière appropriée

Par exemple, une attaque de script intersite réfléchie pourrait ressembler à ceci.
Par exemple, une attaque de script intersite réfléchie pourrait ressembler à ceci.

Voici comment cela fonctionneL'agresseur distribue des liens avec des paramètres manipulés à ses victimes potentielles. Sans le savoir, l'utilisateur envoie une requête "manipulée" au serveur en cliquant sur le lien, et le code malveillant est exécuté en même temps que la réponse du serveur. Comme le code - contrairement au XSS persistant - n'est stocké nulle part, le hacker doit le distribuer en masse aux victimes potentielles. Cela peut se faire par le biais de courriers électroniques ou de réseaux sociaux, par exemple.

scripts intersites persistants

Avec le XSS persistant, les scripts malveillants sont stockés sur le serveur web et livrés chaque fois qu'ils sont appelés par un client. Sont prédestinées à cela les applications web qui stockent les données des utilisateurs sur le serveur et les sortent ensuite sans vérification ni codage (par exemple les forums). Ce type de script peut être particulièrement dangereux pour les blogs et les forums très fréquentés, car les logiciels malveillants peuvent s'y propager rapidement en raison du grand nombre d'utilisateurs.

Ce graphique montre une séquence possible d'une attaque persistante de scripting intersite.
Flux d'une attaque persistante de scripting intersite. Source : Blog SAP

Exemple: Ians un forum, les contributions postées sont stockées dans une base de données. Il n'est pas rare qu'elles soient stockées sans contrôle ni cryptage. Les attaquants profitent de cette opportunité et ajoutent un script malveillant (par exemple à l'aide d'un commentaire) à un message normal du forum. un message normal sur le forum avec un script malveillant (par exemple, à l'aide d'un commentaire). Les utilisateurs reçoivent le lien vers la poste par courrier électronique ou arrivent par hasard à l'entrée correspondante et exécutent le script lorsqu'ils appellent la poste. L'avantage pour le hacker est qu'il peut désormais "espionner" les clients touchés ou les ajouter à son botnet pour de nouvelles attaques.

Scripting intersite local ou basé sur le DOM

Contrairement au XSS persistant et réfléchi, le DOM (Document Object Model) basé sur des scripts intersites fonctionne en exécutant des scripts côté client. Cela signifie que le serveur n'est pas au courant d'une telle attaque et que les mesures de sécurité côté serveur n'aident pas non plus.

Un exemple bien connu d'une telle vulnérabilité est le cas du paquet générique. Le pack générique est un ensemble d'icônes qui est utilisé par de nombreux sites Plugins, y compris Jetpack. Il était possible d'injecter du code malveillant via un fichier HTML dans ce jeu d'icônes.

Après avoir entré cette URL, une alerte javascript est apparue. C'est la preuve que le code javascript saisi pourrait être utilisé pour manipuler la page en question.
Après avoir entré cette URL, une alerte JavaScript est apparue. C'est la preuve que le code JavaScript saisi pourrait être utilisé pour manipuler la page en question. Source : securityaffairs.co

Cependant, une condition préalable à une attaque XSS basée sur le DOM est que l'utilisateur clique sur une URL manipulée. En appelant cette URL, le code malveillant peut être exécuté à travers une brèche dans un script côté client. Entre autres choses, le fait qu'un lien doit d'abord être cliqué fait du XSS basé sur DOM un type d'attaque un peu plus difficile et donc moins probable.

Le graphique montre une séquence possible d'une attaque locale de scripting intersite.
Exemple d'une attaque locale de scripting intersite. Source : heise.de

Exemple: L'utilisateur clique sur l'URL manipulée et envoie une demande à l'application web. L'application web répond en transmettant le code du script (qui est incorrect mais non manipulé) au navigateur pour lancer l'exécution du script. Les paramètres manipulés à partir de l'URL sont maintenant interprétés et exécutés dans le navigateur de l'utilisateur dans le cadre du script. La page web affichée dans le navigateur est ainsi modifiée et l'utilisateur voit maintenant - sans le remarquer - la page manipulée.

Conclusion : assez fréquent et non sans danger, il est donc important d'assurer une protection appropriée.

Les vulnérabilités XSS sont parmi les passerelles les plus courantes pour les codes malveillants. Et souvent, une attaque correspondante constitue la base d'autres attaques, comme le spam, le phishing ou les attaques DDoS. Les attaquants détournent votre site et en abusent pour atteindre leurs propres objectifs.

Les XSS réfléchis et persistants sont particulièrement courants, car les scripts intersites locaux sont plus élaborés et difficiles à mettre en œuvre. Les pages qui La transmission de données d'utilisateurs au navigateur web sans vérification d'éventuels codes malveillants est particulièrement risquée. Il n'est cependant pas si facile de trouver de telles lacunes. En principe, c'est précisément la tâche des fournisseurs de sécurité tels que sucuri et Cie, qui développent constamment leurs mesures de sécurité.

Mais bien sûr, il existe aussi un moyen pour les utilisateurs normaux de WordPress de se protéger contre ces attaques. La mise à jour de tous les éléments de WordPress , par exemple, est une mesure simple mais très efficace. Nous expliquons dans notre prochain article sur le sujet comment vous, en tant qu'opérateur de site, mais aussi en tant qu'internaute, pouvez empêcher le cross-site scripting.

Vous avez encore des commentaires ou des questions ? Alors laissez un commentaire !

En tant qu'administrateur système, Tobias veille sur notre infrastructure et trouve chaque vis pour optimiser les performances de nos serveurs. Grâce à ses efforts inlassables, on peut souvent le trouver la nuit sur le site Slack .

Articles connexes

Commentaires sur cet article

Laisse un commentaire

Ton adresse électronique ne sera pas publiée. Les champs obligatoires sont marqués d'un *.