Le Clickjacking est-il une véritable vulnérabilité de sécurité?
Si je comprends bien, voici comment un attaquant exploiterait le détournement de clics:
- Créer un nouveau site Web malveillantsite.com qui inclut mon site dans un cadre, mais superpose les champs ou boutons de saisie malveillants sur les éléments HTML de mon site.
- Envoyez des e-mails de phishing pour inciter les utilisateurs à cliquer sur le lien qui mène à malveillantsite.com plutôt qu'à mon site (ou utilisez une autre technique pour distribuer le lien de phishing).
- Les utilisateurs saisissent des données ou cliquent sur les éléments malveillants.
- Profit
Les utilisateurs avertis ne cliqueraient pas sur le lien ou remarqueraient que la barre d'adresse est incorrecte. Cependant, beaucoup de gens ne le remarqueraient probablement pas.
Ma question est la suivante: l'attaquant ne peut-il pas réaliser la même chose en utilisant malveillantsite.com comme proxy inverse? Toutes les étapes ci-dessus seraient les mêmes, sauf que malveillantsite.com transmettrait les demandes à mon site, puis insèrerait un <script> tag dans la réponse HTML pour exécuter le code malveillant et ajouter les éléments HTML malveillants. Le X-FRAME-OPTIONS l'en-tête ne serait pas utile dans ce cas car il n'y a pas de trames (et le proxy inverse peut le supprimer de toute façon).
L'attaque repose sur l'utilisateur qui ne vérifie pas la barre d'adresse, donc si l'attaquant peut implémenter la même attaque d'une manière différente qui ne peut pas être vaincue, pourquoi s'embêter avec X-FRAME-OPTIONS ou d'autres protections contre le détournement de clics?
C'est une question très intéressante.
Tout d'abord, commençons par votre scénario: Un utilisateur visitant le site Web www.evil.com qui est un proxy inverse qui charge www.good.com et modifie son contenu. Félicitations ! Vous venez de réinventer un classique attaque MiTM , mais très pauvre. Visiter evil.com signifie que votre navigateur n'enverra pas good.com cookies, ce qui signifie que votre proxy inverse ne pourra pas agir au nom de l'utilisateur. Pour résoudre ce problème, vous devrez maintenant inciter l'utilisateur à se connecter à votre proxy inverse avec son good.com. Félicitations ! Vous avez réinventé une attaque avec une fausse page de destination.
Le scénario que vous décrivez n'a rien à voir avec le détournement de clics, et nous utilisons en fait une protection contre le détournement de clics pour une raison très différente: avec le détournement de clics, un attaquant tromperait un authentifié l'utilisateur à effectuer une action. Même si l'utilisateur visite evil.com, contrairement à votre scénario proposé avec un proxy inverse, sa demande est toujours envoyée à good.com ainsi que les cookies contenant son identifiant de session. Ainsi, l'action sera effectuée dans la session de l'utilisateur authentifié.
Cela vous semble-t-il familier? Oui, car c'est ainsi que fonctionne une attaque CSRF , mais la seule différence est que, avec CSRF, l'action est effectuée par programme .. sauf pour une petite chose: le détournement de clics vainc les mécanismes anti-CSRF. Avec le détournement de clic, l'action est effectuée dans le navigateur de l'utilisateur, par l'utilisateur lui-même et à l'intérieur de la page légitime (chargée dans iFrame).
Donc, en bref: votre attaque proposée est en effet plausible, mais nous utilisons l'anti-clickjacking pour vaincre des attaques complètement différentes. Pour cela, oui, le détournement de clics est en effet un problème de sécurité réel et distinct.