Cet article concerne mon parcours pour comprendre la pratique actuelle de l'anonymisation via la technique du détournement de clics par laquelle un site Web malveillant est en mesure de découvrir l'identité d'un visiteur, y compris son nom complet et éventuellement d'autres informations personnelles. Je ne présente pas ici de nouvelles informations qui ne sont pas déjà accessibles au public, mais je regarde à quel point il est facile de compromettre la vie privée d'un visiteur et de révéler son identité, même lorsqu'il adhère aux meilleures pratiques de sécurité et utilise une mise à jour. -date navigateur et système d'exploitation.
Motivation initiale - Google YOLO
Mon voyage a commencé lorsque j'ai lu l'excellent article de blog Google YOLO de @filedescriptor sur une vulnérabilité de détournement de clics du service Google YOLO (You Only Login Once), un widget Web qui fournit une connexion en un clic intégrable sur les sites Web.
Le widget peut être utilisé comme une menace pour la vie privée. En fait, il est possible de créer un site Web avec le widget Google YOLO et de masquer le widget pour qu'il ressemble à un bouton inoffensif. Lorsque le bouton apparemment inoffensif est cliqué, la victime se connecte sans le savoir au site Web avec son compte Google, et transmet ainsi son identité, y compris son nom complet et son adresse e-mail, au propriétaire du site Web.
Cependant, comme la plupart des sites Web que vous utilisez connaissent probablement votre identité de toute façon, ce n'est pas le problème le plus grave, mais cela peut toujours se retourner. Pensez, par exemple, à remplir une enquête sensible qui prétend être anonyme. Comme vous ne vous êtes jamais connecté au site Web de l'enquête, vous pourriez penser qu'il n'a aucun moyen de connecter vos réponses à votre identité, mais ce n'est peut-être pas le cas.
Au moment où j'ai lu le blog de Google YOLO, le problème avait déjà été résolu par Google en limitant le service YOLO à une liste de partenaires.
Le billet de blog montre également le détournement de clics avec le widget Facebook Like, mais quand je l'ai essayé, il a demandé une confirmation, comme ceci:
La demande de confirmation rend l'attaque de détournement de clic impossible - même si la victime clique sur le bouton J'aime deux fois sans le savoir, elle devra toujours confirmer l'action dans la nouvelle fenêtre contextuelle ouverte. La fenêtre contextuelle, étant une toute nouvelle fenêtre, ne peut pas être manipulée par le site Web de l'attaquant et n'est pas sujette au détournement de clics. L'inconvénient est que la solution nuit à la convivialité, nécessitant des actions supplémentaires à chaque fois, même pour une utilisation légitime du bouton Like.
Il m'a donc semblé que le problème avait été résolu par les géants de la technologie, alors j'ai oublié pendant un moment, jusqu'à ce que j'aie une idée…
Le Widget Commentaires Facebook: "Typejacking"
Un jour, alors que je naviguais sur le Web, je suis tombé sur un site Web qui utilisait le plugin Facebook Comments pour permettre aux visiteurs de commenter les articles de son site Web au bas de la page. En parcourant, je me suis souvenu de ce que j'avais lu sur le blog de Google YOLO à propos du clickjacking, et j'ai pensé: le clickjacking ne peut plus être appliqué sur les principaux services, mais qu'en est-il du «typejacking»? Que se passe-t-il si je prends le plugin de commentaires et l'intègre sur mon site Web, le déguisant en un formulaire avec un objectif différent? Ensuite, lorsque la victime sans méfiance arrive et insère du texte, n'importe quel texte, et le soumet en tant que commentaire Facebook sur ma page, je peux apprendre son identité en vérifiant quel compte Facebook vient de publier le commentaire.
J'ai donc commencé à travailler sur une page Web de preuve de concept qui illustre la technique. En travaillant dessus et en essayant différentes approches, j'ai accidentellement découvert que le widget Like, celui que je pensais nécessiter une confirmation, fonctionne sans confirmation sur mon site! En lisant le widget Facebook Like sur Internet, j'ai découvert que Facebook, contrairement à Google, utilise une liste noire pour appliquer une protection contre le détournement de clics.
Bien que la méthode choisie par Facebook pour protéger ses utilisateurs contre le détournement de clics puisse se prémunir contre une récolte massive de likes - ils peuvent remarquer qu'une grande quantité de likes proviennent d'un seul site Web - et même annuler les likes, cela ne protège pas les utilisateurs de la - menace d'anonymisation. Un attaquant peut facilement créer un nouveau site Web, en utilisant le détournement de clics avec le widget J'aime, puis envoyer la page à un nombre limité de victimes et révéler leur identité en suivant les likes sur Facebook.
À ma grande surprise, la technique du likejacking, qui est le terme appliqué à la stratégie d'utilisation du clickjacking pour gagner des likes, existe depuis au moins 2010 . D'une certaine manière, aujourd'hui, 9 ans plus tard, c'est toujours un problème. De plus, quand on parle de détournement, les gens mentionnent rarement le problème de la désanonymisation. Bien qu'il a été mentionné plus tôt que 2012 , je pense qu'il n'y a pas assez conscience de, surtout de nos jours où de plus en plus de gens ont commencé à comprendre l'importance de la vie privée en ligne.
Soit dit en passant, en ce qui concerne cette preuve de concept de détournement de type - vous avez peut-être vu un CAPTCHA que vous deviez entrer pour pouvoir voir cet article. Vous avez probablement compris maintenant que ce n'était pas un vrai CAPTCHA, [nom_du_touriste] :) Si vous l'avez manqué, vous pouvez jouer avec la page de preuve de concept ici , cette fois avec une case à cocher pour révéler le widget déguisé.
Au-delà du clickjacking et du typejacking
tout en réfléchissant au concept de détournement de clics, je me suis demandé ce qui pouvait être fait d'autre en exploitant la capacité d'intégrer et de manipuler un widget tiers sur un site Web malveillant. Les techniques de détournement de clics et de détournement de type incitent l'utilisateur à interagir avec le widget. Que faire si nous incitons l'utilisateur à obtenir des informations à partir du widget à la place?
Apparemment, quelqu'un y a pensé aussi. Une recherche rapide m'a conduit à l'article Tell Me About Yourself: The Malicious CAPTCHA Attack qui analyse cette technique. Voici un exemple de l'article qui montre comment un attaquant peut amener la victime à révéler son propre nom sans le savoir en masquant le widget comme un CAPTCHA sournois:
Prévention du détournement de clics pour les propriétaires de sites Web
À ce jour, il n'existe toujours aucun moyen fiable d'empêcher le détournement de clics.
En 2009, l'en-tête HTTP X-Frame-Options a été introduit, qui offre une protection partielle contre le détournement de clic. L'en-tête permet au propriétaire d'un site Web de spécifier quelles pages ne doivent pas être encadrées. Un navigateur qui connaît l'en-tête refusera de charger ces pages dans un cadre. Bien que cela empêche parfois le détournement de clics, cela n'aide pas avec les widgets destinés à être encadrés, tels que le widget J'aime ou le widget de commentaires.
En regardant l'en-tête X-Frame-Options, je me suis dit, pourquoi ne pas prendre une mesure de prévention similaire qui permet toujours le cadrage? Pensez au widget Like, par exemple: Y a-t-il une raison pour qu'une page Web dessine sur le widget? Pour changer sa taille et son opacité? Pour effectuer d'autres manipulations telles que des filtres CSS? La seule raison pour laquelle je peux penser est le détournement de clics. Alors pourquoi ne pas introduire une nouvelle option X-Frame-Options telle que X-Frame-Options: Isolate, qui permettra le cadrage, mais s'assurera que le cadre ne peut pas être falsifié et que le site Web parent ne peut pas le recouvrir? Comme pour mes idées précédentes, je n'étais pas le premier à proposer cette idée .
Jusqu'à ce que les navigateurs mettent en œuvre une telle protection, les propriétaires de sites Web n'ont qu'une seule option: exiger une interaction supplémentaire de l'utilisateur, éventuellement avec une fenêtre contextuelle isolée. Nous avons vu que Facebook le fait avec le widget Like, mais uniquement pour les sites Web suspects hébergeant le widget. Apparemment, Facebook valorise la convivialité des utilisateurs plus que leur vie privée.
Atténuation du détournement de clics pour les utilisateurs
Après avoir essayé plusieurs solutions, je suis arrivé à la conclusion que le blocage des cookies tiers est la meilleure atténuation pour le détournement de clics. Cela n'empêche pas le détournement de clics en soi, mais comme le cadre intégré ne recevra pas les cookies du visiteur, l'attaquant ne pourra pas faire beaucoup de mal.
Ce qui est bien avec le blocage des cookies tiers, c'est que la plupart des navigateurs ont une option pour le faire hors de la boîte. Pas besoin d'installer des extensions tierces ou de chercher des solutions différentes pour différents navigateurs ou appareils.
L'inconvénient est que les widgets légitimes, tels que le widget Like ou le widget de commentaire, cesseront de fonctionner. Je ne me souviens pas en avoir raté un, mais bien sûr votre kilométrage peut varier.
Un avantage supplémentaire du blocage des cookies tiers est qu'il peut protéger contre les attaques des canaux secondaires, qui ne nécessitent pas d'interaction de l'utilisateur. Par exemple, cette technique montre l'utilisation d'une fonctionnalité CSS3 pour anonymiser les utilisateurs de Facebook sans interaction supplémentaire avec l'utilisateur. Un autre exemple d'une vulnérabilité ancienne mais intéressante qui pourrait être évitée en bloquant les cookies tiers est le vol générique inter-navigateurs inter-domaines ( problème Chromium pertinent ).
Sommaire
Si rien d'autre, je veux que vous reteniez de cet article: envisagez de bloquer les cookies tiers afin de protéger votre identité en ligne. Voici l'un des nombreux guides qui montrent comment bloquer les cookies tiers dans divers navigateurs.
J'espère que cela contribuera à faire prendre conscience du problème actuel du détournement de clics qui n'a pas été résolu depuis 2010. Peut-être que les fournisseurs de navigateurs envisageront de mettre en œuvre une mesure de prévention pour limiter la manipulation des trames.
Aucun commentaire:
Enregistrer un commentaire