Cross-Site-Scripting - Comment les pirates informatiques s'emparent de votre site

Tobias Schüring Mis à jour le 15.01.2020
6 Min.
Scripting_XSS intersites

XSS, injection SQL, XMLrpc - lorsqu'une mise à jour de sécurité WordPress est publiée, le Rapports de mise à jour surtout des abréviations cryptiques. Même s'il est clair que ces mises à jour sont nécessaires et que le renforcement de la sécurité est très apprécié, il est important de comprendre ce qui se cache derrière ces failles de sécurité. Car ce n'est que si vous comprenez quelles lacunes les mises à jour comblent que vous pouvez prendre une décision éclairée. C'est pourquoi nous allons nous concentrer aujourd'hui sur le cross-site scripting, ou XSS, de loin l'attaque complexe la plus courante sur les WordPress sites.

Les attaques de pirates informatiques peuvent facilement être comparées à celles de cambrioleurs. Brute Force Attaques sont plus proches de la méthode du pied-de-biche. Le criminel se presse contre l'outil jusqu'à ce que la porte ou la fenêtre soit brisée. Les attaques contre les vulnérabilités du XSS, en revanche, sont plus sophistiquées : Le cambrioleur sait exactement par où commencer et accède à une page de manière très ciblée.

Dans le cadre du cross-site scripting, les failles de sécurité des sites web sont ainsi exploitées de manière ciblée. Les pirates informatiques introduisent en douce 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 attaquants peuvent ainsi obtenir des informations confidentielles ou accéder à l'ordinateur de l'utilisateur endommagé. De telles attaques ne sont pas vraiment rares : Une bonne moitié des vulnérabilités découvertes par le fournisseur Wordfencede sécurité en 2015 et 2016 Pluginsétaient des vulnérabilités de type "cross-site scripting. Souvent, une attaque XSS constitue alors la "base" d'autres attaques, telles que le spam, le phishing ou même les attaques DDoS. C'est pourquoi aujourd'hui, d'une part. comment fonctionne exactement le script intersitequi Types d'attaques il y a et le danger des attaques.

Le cross-site scripting fonctionne toujours de la même manière : un code malveillant pénètre sur votre site par une brèche

Les scripts intersites sont toujours un danger lorsqu'une application web transmet les données utilisateur saisies au navigateur web sans vérifier le code de script éventuellement existant. Un bon exemple d'une telle application web est un chat de soutien.

À propos de l'application web elle-même les scripts malveillants peuvent s'introduire sur le serveur. De là, le code malveillant finit tôt ou tard chez les clients concernés. Un bon exemple d'une telle vulnérabilité du XSS est le Bug dans la méta-information de l'image dans 2WooCommerce.6.2. Par une faille, il était possible pour les attaquants d'infiltrer du code HTML dans les méta descriptions des images depuis l'extérieur. Tout client qui aurait maintenant regardé de plus près la photo en question (par exemple en cliquant sur la photo) risquerait d'être attaqué. Par exemple, un pirate informatique pourrait avoir infecté les ordinateurs de vos clients avec un virus.

Astuce populaire en matière de scripting intersite : les formulaires manipulés

Le XSS peut également permettre aux pirates de remplacer des formulaires inoffensifs par des formulaires manipulés. Ces formulaires recueillent ensuite les données des victimes (les visiteurs de votre site !). DD'ailleurs, avor ne peut pas protéger même le cryptage SSL. Car HTTPS "seulement" 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 n'est d'aucune utilité.

Comme pour les autres types d'attaques, la cible des pirates informatiques est dans la plupart des cas le Monétiser leurs machinations. Concrètement, cela signifie que les attaquants volent des données qu'ils vendent ensuite, ou qu'ils veulent infecter des sites afin de les intégrer dans un réseau de zombies qui est ensuite loué.

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

Les attaques de type "cross-site scripting" peuvent être divisées en trois types :

En gros, les attaques du XSS se déroulent comme suit : Les codes malveillants sont infiltrés là où l'on attend une intervention de l'utilisateur (par exemple, lors d'une recherche sur une page interne). Dans le cadre de la réponse du serveur, le code malveillant est ensuite exécuté au niveau du client, c'est-à-dire dans le navigateur de l'utilisateur. Et c'est exactement là que les dommages respectifs sont causés, par exemple le vol de données d'utilisateur.

Scénario intersites réfléchi

Certaines entrées, telles que les requêtes de recherche, sont reflétées par le serveur. Cela signifie que, par exemple, après avoir entré "Test" dans la zone de recherche, la page affichera "Vous avez recherché 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 s'appelle. Le code malveillant n'est donc que temporairement infiltré dans la page concernée, mais n'est pas sauvegardé.

En juillet, en Plugin Statistiques du WP une telle vulnérabilité a été trouvée (et réparée le jour même !). Une valeur d'entrée sur la page "wps_visitors_page" a été transmise sans être vérifiée, ce qui a entraîné une vulnérabilité due au XSS réfléchi. Par exemple, une page pourrait être piratée si un administrateur avait précédemment cliqué sur un lien manipulé de manière appropriée

Par exemple, une attaque de type "cross-site scripting" réfléchie peut ressembler à ceci.
Par exemple, une attaque de type "cross-site scripting" réfléchie peut ressembler à ceci.

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

Scénarios intersites persistants

Avec le XSS persistant, ou persistant, les scripts malveillants sont stockés sur le serveur web et sont livrés chaque fois qu'un client les appelle. Sont prédestinées à cette fin les applications web qui stockent les données des utilisateurs sur le serveur et les restituent 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 le malware peut se propager rapidement en raison du grand nombre d'utilisateurs.

Ce graphique montre une séquence possible d'une attaque persistante de scripting intersite.
Procédure d'une attaque persistante de type "cross-site scripting". Source : Blog SAP

Exemple: Ians un forum, les contributions postées sont stockées dans une base de données. Ils sont souvent stockés non contrôlés et non cryptés. Les agresseurs profitent de cette occasion pour infliger une le forum publie un script malveillant (par exemple, en utilisant un commentaire). Les utilisateurs reçoivent le lien correspondant à la poste soit par e-mail, soit ils accèdent à l'entrée correspondante par hasard et exécutent le script en appelant la poste. Avantage pour le hacker : il peut désormais "espionner" les clients affectés ou les ajouter à son botnet pour de nouvelles attaques.

Scripting intersite local ou basé sur 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.

Un exemple bien connu de cette lacune est le cas du paquet générique. Le pack générique est un ensemble d'icônes qui est utilisé par beaucoupPlugins, y compris par le Jetpack. En utilisant un fichier HTML dans ce jeu d'icônes, il a été possible d'infiltrer du code malveillant.

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 respective.
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 un trou dans un script côté client. Entre autres choses, le fait qu'il faille d'abord cliquer sur un lien rend le XSS basé sur le DOM un peu plus difficile et donc moins probable comme type d'attaque.

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

Exemple: L'utilisateur clique sur l'URL manipulée et envoie une requête à l'application web. Celui-ci réagit en transmettant le code du script (qui est défectueux 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. Le site web affiché dans le navigateur est donc modifié et l'utilisateur voit maintenant - sans s'en apercevoir - la page manipulée.

Conclusion : assez souvent et non sans danger, une protection appropriée est donc importante

Les vulnérabilités XSS sont l'un des points d'entrée les plus courants pour les codes malveillants. Et souvent, une attaque correspondante constitue la base de nouvelles attaques, comme le spam, le phishing ou même 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 complexes et difficiles à mettre en œuvre. Les pages qui Les utilisateurs qui saisissent des données dans leur navigateur sans vérifier la présence d'éventuels codes malveillants sont particulièrement exposés. Mais trouver de telles lacunes n'est pas si facile. 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, les WordPress utilisateurs normaux ont également la possibilité de se protéger contre ces attaques. La mise à jour de tous WordPress les éléments est une mesure simple mais très efficace. Dans notre prochain article, nous expliquerons comment vous, en tant qu'opérateur de site, mais aussi en tant qu'internaute, pouvez empêcher le cross-site scripting.

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

En tant qu'administrateur système, Tobias veille sur notre infrastructure et trouve tous les moyens possibles pour optimiser les performances de nos serveurs. Grâce à ses efforts inlassables, il est souvent Slack retrouvé la nuit.

Articles connexes

Commentaires sur cet article

Ecrire un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués par * .