Comment les pirates informatiques permettent-ils à la victime d'accéder à une URL d'attaque XSS?
Si je comprends bien, l'idée de base de XSS est de laisser le navigateur de l'utilisateur exécuter du code malveillant créé par les pirates.
Dites, si une page a une vulnérabilité de chargement de script arbitraire lorsque l'utilisateur accède à cette URL:
http://www.example.com/apage?filename=malicious.js
Ensuite, le navigateur chargera le malicious.js fichier sans aucune question, et l'utilisateur sera piraté.
Ma question est, comment les pirates font-ils pour que l'utilisateur accède à une telle URL?
Comme dans le cas ci-dessus et toutes les autres techniques similaires, toutes ont une condition préalable: l'utilisateur doit prendre des mesures qu'il ne prendrait généralement pas.
Si le pirate doit venir dire "salut, il y a quelque chose de drôle, regarde!" pour tout le monde, ce ne sera pas une attaque très efficace.
Alors, y a-t-il des astuces pour que cela se produise automatiquement? Ou des cas réels qui provoquent cela?
l'utilisateur a fait des actions qu'il ne fera pas comme d'habitude
Cliquer sur un lien semble être une action habituelle pour la plupart des utilisateurs.
Voir par exemple cette étude , dans lequel 56% des utilisateurs ont cliqué sur les liens dans les e-mails d'un expéditeur inconnu, et ~ 40% ont cliqué sur les liens envoyés via Facebook (bien que 78% soient conscients des possibles danger). 50% ont déclaré ne pas avoir cliqué sur le lien parce qu'ils ne connaissaient pas l'expéditeur.
C'est déjà un taux de réussite impressionnant. Si la victime connaît l'attaquant ou si l'attaquant usurpe l'identité d'une personne qu'elle connaît, ce taux pourrait être encore augmenté.
Sur les réseaux sociaux, le XSS reflété peut également être vermifuge. En plus de l'action malveillante, le script injecté pourrait envoyer des messages contenant le lien à tous les amis de la victime (quelque chose comme ça, par exemple, est arrivé à Twitter ).
En plus du courrier électronique, des liens peuvent également être distribués dans des forums, des blogs, des trackers de problèmes, etc. Cela est par exemple arrivé à Apache .
C'est ce que je me suis toujours demandé, et quand on me demandait, on me disait généralement que "les utilisateurs ne font pas attention et cliquent sur tout". Ce qui dit que cela donne l'impression que XSS réfléchi n'est pas vraiment une vulnérabilité de logiciel, mais une vulnérabilité des utilisateurs. Tout cela me semblait étrange parce que je suis le genre de personne qui vérifie généralement l'aperçu du lien (en survolant avec la souris sur le lien dans le navigateur), et si quelqu'un me dit de cliquer sur cette question sur StackExchange et je repère le format bizarre (voir le chemin), je ne vais pas cliquer.
Cependant, je dois dire qu'il existe des moyens de rendre le XSS réfléchi plus dangereux qu'il n'y paraît au premier abord. Tenez compte des points suivants:
- Clics automatiques, redirections ou astuces similaires: vous n'avez pas à cliquer, tout ce que vous avez à faire est d'atterrir sur un site Web malveillant qui se redirigera automatiquement vers le site Web cible et exécutera le javascript malveillant. Si vous êtes connecté sur le site web cible, l'attaquant vous fera exécuter du javascript arbitraire et effectuer des actions malveillantes (envoyer ou supprimer des trucs, etc.)
- Sites Web qui ont généralement des URL longues ou complexes (non conviviales) et que l'utilisateur a de toute façon confiance. J'ai tendance à voir ça sur Amazon, les liens sont quand même illisibles.
- Les navigateurs qui ne vous permettent pas de voir un aperçu facilement, comme sur les navigateurs mobiles ou d'autres logiciels où ce n'est pas aussi simple que de survoler. Je dois admettre que je ne prends pas le temps de vérifier les liens sur mobile, je tape simplement, bien que sur mobile j'essaie seulement d'utiliser une sélection restreinte de sites Web de confiance.
- L'attaquant connaît la victime, sait comment les convaincre de cliquer sur un lien ou de visiter une page, et la victime peut même, dans certains cas, faire confiance à l'attaquant. Un e-mail aléatoire d'un parfait inconnu n'est pas la même chose qu'un message privé Facebook d'une connaissance (malveillante).
- Seins et lols: des images avec des seins, des lolcats, etc. peuvent vous faire perdre temporairement conscience, et vous pourriez avoir l'impression de devoir cliquer dessus tout de suite comme si c'était une loi de la physique.
Donc, comme vous pouvez le voir, les risques associés à XSS réfléchi peuvent varier considérablement, selon l'utilisateur, la confiance accordée au site Web affecté, les actions possibles sur le site Web cible, etc. Néanmoins, cela reste toujours une vulnérabilité logicielle dans tous les cas, car par définition, il permet l'exécution arbitraire de javascript en exploitant une faiblesse de la désinfection des entrées.
L'exemple que vous avez donné est très trivial. Il existe de nombreuses applications qui ont des dizaines de paramètres GET dans l'URL en cours de partage. Tout ce dont l'attaquant a besoin, c'est que l'un d'entre eux soit vulnérable aux XSS réfléchis pour que cela réussisse. Si le lien que quelqu'un attend est long et complexe et que ce qu'il obtient est long et complexe, il se peut qu'il ne se penche pas sur chaque paramètre.
Ils pourraient également utiliser un raccourcisseur d'URL.
Il existe deux principaux types de XSS, réfléchissant et persistant. Le XSS persistant est lorsqu'il est stocké sur le serveur, affectant les autres utilisateurs, tandis que le réfléchissant n'est pas stocké, mais peut toujours affecter d'autres utilisateurs.
Une méthode que j'ai vue consiste à stocker quelque chose comme une redirection dans un commentaire qui a un mauvais nettoyage. De cette façon, le code est stocké côté serveur et lorsque quelqu'un demande la page, le code est chargé avec les commentaires, ce qui déclenche ensuite le bloc de code. Cela peut ensuite rediriger la victime vers le site Web de l'attaquant, où d'autres choses malveillantes pourraient se produire, par exemple Fausses pages de connexion pour les collecteurs d'informations d'identification, les piles d'annonces, etc.
Si vous avez besoin de plus d'informations, faites-le moi savoir, je pourrai les modifier à mon retour sur le PC et ajouter plus de détails.
EDIT: Par exemple, si un site était susceptible de ce type d'attaque, un commentaire pourrait être laissé redirigeant tous les utilisateurs qui ont visité cette page vers un nouveau site, ce nouveau site pourrait être une copie presque identique du site d'origine, conçu pour vous obliger à vous reconnecter, puis à voler les informations d'identification. Parce que les gens ont tendance à utiliser les mêmes mots de passe sur plusieurs sites, ces informations d'identification pourraient ensuite être utilisées pour se connecter ailleurs, etc.
Fondamentalement
Chaque fois qu'un développeur Web fait ceci:
<script src="someOtherDomainThanThisOne"></script>
C'est une avenue possible pour XSS. Le site que l'utilisateur visite n'a pas besoin d'être le moins du monde compromis, seul le site hébergeant le script.
Par exemple, si je suis un développeur Web travaillant sur mon site Web widgets.com et que je trouve cette nouvelle bibliothèque js flashy. Au lieu de l'héberger directement depuis mon site, j'ai choisi le chemin non sécurisé de l'inclure (via le script src) de cooljslibs.com. À un moment donné dans le futur, soit cooljslibs.com devient voyou, soit quelqu'un le pirate et compromet les fichiers hébergés. Maintenant, widgets.com n'a été piraté d'aucune façon, mais comme il exécute aveuglément le code de cooljslibs.com, il a compromis ses utilisateurs et son site.
Cela peut être partiellement atténué en utilisant l'intégrité des sous-ressources, ce qui oblige fondamentalement une vérification de hachage sur le fichier tiers. Il est toujours préférable de l'héberger vous-même en plus de cela. Vous pouvez en savoir plus ici . ex:)
<script src="https://example.com/example-framework.js"
integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
crossorigin="anonymous"></script>
Je pense qu'un excellent exemple de la façon dont un XSS peut être utilisé dans la nature est la récente violation de données de British Airways. Comme expliqué dans cet article: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ les attaquants ont stocké un javascript malveillant, remplaçant un script habituel sur la page de paiement , cela volerait la carte de crédit saisie par l'utilisateur. Bien que ce ne soit pas une attaque XSS typique car ils avaient accès au serveur pour changer le script, c'est toujours une démonstration très valable d'une telle attaque.
Si vous pouvez stocker d'une manière ou d'une autre du javascript valide sur un site Web (XSS stocké), vous pouvez alors voler le cookie de l'utilisateur et usurper l'identité de cet utilisateur et accéder aux mêmes informations (comme les données de profil).
En ce qui concerne le XSS reflété, vous devez faire de l'ingénierie sociale et obliger l'utilisateur à cliquer sur un lien malveillant, comme d'autres l'ont souligné.
Pour certaines attaques, la victime doit visiter la page de l'attaquant. Il y a deux façons de procéder:
- Hameçonnage. Envoyez à la victime un e-mail, une page Facebook, une invitation LinkedIn avec un lien prétendant être autre chose. Le taux de réussite dépend de la quantité d'efforts consacrés à la campagne, mais des taux de réussite supérieurs à 50% ne sont pas rares. Surtout parce que le nom de domaine correspond: vous essayez de tromper les utilisateurs de somegoodsite.com en cliquant sur un lien somegoodsite.com, et cela peut généralement être fiable.
- Inclusion à l'intérieur du site lui-même. Parfois, le site permet d'ajouter du contenu utilisateur. Si l'attaquant peut ajouter un iframe à sa page de profil, toute personne accédant à son profil sera attaquée. Cependant, il est assez rare de pouvoir ajouter un iframe à n'importe quel site.
- Attaque de l'homme au milieu. Lors d'une attaque par l'homme du milieu, l'attaquant peut modifier les données non chiffrées. Même si somegoodsite.com utilise HTTPS, l'attaquant peut injecter un iframe dans une page Web qui n'utilise pas HTTPS et amener votre navigateur à visiter l'URL.
- Annonces. Certains sites diffusent des publicités intrusives qui chargent une page dans un iframe ou même dans une nouvelle fenêtre. Je reçois parfois ceux-ci avec le message que j'ai gagné un iPhone gratuit, mais vous pouvez également les exécuter avec une charge utile XSS. Cependant, je pense que les sites qui autorisent des publicités aussi intrusives sont assez rares.