La désinformation peut prendre de nombreuses formes, mais elle essaye généralement de se faire passer pour légitime en copiant (souvent grossièrement) des sites officiels. Ajoutez l’empressement des utilisateurs à partager des informations sans vérifier outre-mesure et vous avez un combo gagnant (enfin perdant). Les Twitter Cards en sont victimes en ce moment, mais ce ne sont pas les seules.
Comme l’explique Wikipédia, le cloaking (ou masquage) est une technique qui consiste « à présenter un contenu de page web différent suivant que le client distant est un robot de moteur de recherche ou un internaute humain ».
Cette distinction peut se faire suivant différentes techniques, l’adresse IP et l’user-agent sont les deux principales. L’user-agent est une chaine de caractères permettant d’identifier le type de navigateur, sa version, le système d’exploitation de la machine, etc.
Deux salles, deux ambiances
Cela permet ainsi d’afficher une mise en page différente sur un smartphone et sur un ordinateur de bureau. On peut aussi adapter la page au navigateur, ce qui était parfois indispensable à l’âge d’or d’Internet Explorer de Microsoft.
Mais l’utilisation de l’user-agent peut aussi être détourné. Google donne un exemple de ce qu’il ne faut pas faire : afficher « une page sur des destinations de voyage pour les moteurs de recherche et une autre sur des médicaments à prix réduit pour les utilisateurs ».
Les Twitter Cards détournées
C’est ce qui se passe en ce moment sur certaines publications X (anciennement Twitter), même si le phénomène n’est pas nouveau ni limité à ce réseau social. Les Twitter Cards sont en effet détournées pour rediriger des utilisateurs sur des fausses informations, tout en se faisant passer pour des sites légitimes.
En voici un exemple :
La Twitter Card indique que l’aperçu vient de « lemonde.fr ». C’est vrai, mais ce n’est pas forcément cette page que l’utilisateur va voir s’il clique sur le lien, comme l’explique Nico Popy sur X. Suivant votre user-agent (mais cela peut être un autre paramètre), vous serez redirigé vers le site officiel du Monde, ou bien vers un site frauduleux en insidetodayreportsnow[.]xyz.
Ce dernier reprend un design proche de celui du Monde. La supercherie ne tient pas longtemps si on regarde un tant soit peu attentivement. Il suffit par exemple d’essayer de cliquer sur le bandeau supérieur (qui ne se déroule pas). Cette mise en page peut néanmoins suffire à tromper des utilisateurs. Sur ce site, on retrouve donc une fausse information montée de toutes pièces.
Sur l’image ci-dessous, la même URL (t.co/xxxx) redirige vers un site frauduleux si on ne change pas notre user-agent, alors qu’on arrive sur Le Monde avec un user agent ne correspondant pas à celui d'un navigateur.
Une redirection peut en cacher une autre
Mais comment se fait-il qu’il existe deux versions ? Un petit passage par Wheregoes (qui permet de suivre les redirections d’un lien sans cliquer dessus) donne la réponse : il y a deux redirections différentes. La première, en 301 (redirection permanente) renvoi vers le site frauduleux insidetodayreportsnow[.]xyz. La seconde, en 302 (redirection temporaire) vers le site du Monde.
Les utilisateurs classiques restent bloqués à la première redirection, tandis que ceux avec un user-agent spécifique (les moteurs de recherche par exemple) sont renvoyés vers la seconde page.
Dans le cas de Twitter ou d’autres applications proposant un aperçu, c’est le second site qui est pris en compte, avec donc la miniature et la provenance du Monde. Les utilisateurs ont ainsi l’impression de se rendre sur un site légitime, alors que non.
Nous avons testé le lien dans différentes applications proposant une prévisualisation. LinkedIn, Twitter et Mattermost par exemple propose un aperçu du site du Monde, alors que les internautes verront bien (trop) souvent le site frauduleux.
Résultat des « cards » de prévisualisation sur Mattermost et LinkedIn.
Commentaires (23)
#1
Rien que pour le site WhereGoes, je suis content d'avoir lu cet article :) #Bookmark
#1.1
Il y a ceux qui utilisent des raccourcisseurs d'URL (on se demande pourquoi ?) et les autres.
Je suis surpris que tu soies surpris.
#2
#2.1
Redirection : rien n'est généré.
Il n'y a aucun contenu "frelaté" : ce qui est présenté à client reconnu comme navigateur classique est différent de ce qui est présenté aux autres (dont les robots).
Les robots (ou plutôt la logique inverse : les "agents non-reconnus comme des navigateurs classiques") sont redirigés vers un contenu final légitime, d'où la synthèse image & nom de domaine) est faite. C'est exactement comme cela que tout "lien enrichi" ont de tous temps été créés.
#3
#4
Merci beaucoup Sébastien (et Next) ! Comme d'habitude, vous êtes des champions !
#5
Ou c'est juste un bug/feature qui fait que les robot de prévisualisation (et d'indexation?) suivent la redirection temporaire là où un navigateur "standard" va rester sur la redirection "normale"? (Ce qui me paraît aberrant).
Mon cerveau manque d'information technique (et de café) pour bien comprendre la bail du pourquoi du comment là.
#5.1
Il ne s'agit pas de redirection au niveau DNS, le terme n'est même pas dans l'article.
Il s'agit de redirection d'URL faite par un serveur WEB.
Un serveur Web a bien accès au user-agent du navigateur contrairement à un serveur DNS.
#5.3
Certes DNS n'est pas cité, mais de base c'est les seule redirections que je connais et les codes 301 302 me disaient quelque-chose du coup j'ai mixé ^^".
Je trouve l'explication de fdorin vachement plus claire, et avec ça et deux de café plus tard, je comprends le cheminement sur la capture de wheregoes :p
#5.2
- un client A visite une URL : http//raccour.ci/sdlfiugt
- le site raccour.ci redirige via une redirection HTTP (HTTP, pas DNS !) vers le site derrière. Par exemple, http://monsitemalveillant/?p1209843
- le site malveillant est interrogé, et pour répondre au client A, il va regarder le UserAgent qui est dans la requête
- si le UserAgent correspond à un navigateur classique, alors le client A va avoir le contenu malveillant (de la pub, des scripts malveillants, ou que sais-je encore, sur fond de copie légitime parfois)
- si le UserAgent ne correspond pas à un navigateur classique, alors le client A est redirigé vers le site "original" (par exemple, le monde).
Ainsi, les moteurs d'indexation ou ceux qui font apparaitre des miniatures voient le site légitime, tandis que les véritables utilisateurs voient le contenu vérolé.
#5.4
#5.5
#5.6
Dans le cas de 301, "Moved permanently", le serveur renvoie ce code au client avec l'adresse (Location) du nouveau document à consulter pour lui indiquer que le chemin désiré a été déplacé de manière permanente.
Par exemple, mon site répondait avait sous
monsite.fr/index.phpet depuis c'estmonsite.fr/index.html, le serveur renvoie cette info au client avec le code 301. Ce code a aussi pour effet de demander aux moteurs de recherche de mettre à jour leur index.Dans le cas de l'URL réduite, il s'agit de l'étape où le lien court est traduit avec l'URL complète.
Cependant, la "vraie" URL renvoie un HTTP 302 ("Found") qui est un code ayant une petit particularité : les moteurs de recherche ne mettent pas à jour leur index quand ils reçoivent ce message. Car il s'agit d'une redirection considérée comme temporaire. Là où le navigateur du client va suivre l'adresse de redirection.
C'est là que les bactéries attaquent car l'URL malveillante répondant un code 302, elle trompe les clients qui ne sont pas des navigateurs Web et renvoie une carte réputée être la destination de l'URL raccourcie.
En fait, de ma compréhension, c'est un usage détourné du code HTTP 302 qui est utilisé comme si c'était HTTP 307 ("Temporary redirect") qui profite du fait que tous les clients ne l'ont pas forcément implémenté comme la spécification l'attendait.
#5.8
Attention, un robot suivra aussi la redirection pour accéder à la page finalement servie et indexer son contenu même s'il ne met pas à jour l'adresse. D'ailleurs ici ce sont bien les robots des réseaux sociaux à qui est servie une redirection 302 supplémentaire pour qu'ils pensent que le lien donné mène sur lemonde.fr.
Et donc de ma compréhension non, ça ne s'appuie pas sur le comportement du client : la redirection n'est tout simplement pas présentée si l'UA correspond à un navigateur.
#5.9
Et ouais quand on fait joujou avec Apache et son
.htaccesset qu'on ne comprend pas pourquoi une redirection est tjr effective alors qu'on l'a retirée...Donc faut faire attention avec la 301.
#5.10
- 301 : redirection permanente
- 302 : redirection temporaire
- 307 : redirection temporaire (bis)
Sur le côté permanent / temporaire : cela permet de gérer soit un déménagement, soit des travaux de maintenance par exemple. Pour donner des idées : lors du déménagement de nextinpact vers next.ink, le site nextinpact redirige vers next.ink via une redirection permanente. Il n'y a plus de raison de conserver l'ancienne URL (le contenu a été déplacé) si ce n'est pour indiquer où il se trouve maintenant pour permettre d'y accéder. En analogie routière : la route est définitivement fermée, prenez la rocade qui a été mise en place.
Le temporaire, est, comme son nom l'indique bien... temporaire (vous ne vous y attendiez pas, avouez !!!). Une redirection temporaire peut avoir plein de cause. Maintenance serveur, mode dégradé, ... et dénote, normalement, une situation exeptionnelle qui n'est pas sensée durer. Quand le site ne nextinpact a connu un gros plantage il y a quelques mois, et que le site a été redirigé vers la beta, c'était de manière temporaire. En analogie routière : la route est temporairement fermée (réfection, installation électricité / gaz / autre, etc.), suivez les panneaux de déviation.
Pour terminer, une redirection permanente peut être mise en cache par le navigateur, alors qu'une temporaire ne doit surtout pas l'être.
Maintenant, la différence entre le 302 et le 307 (hormis que cela pourrait être des gammes de voiture). Tout se joue au niveau des verbes HTTP. En HTPP, il en existe plusieurs, le plus connu est le GET (on récupère les ressources) et le POST (en envoie des données, par exemple, un formulaire). Mais avec les API REST, on a vu se démocratiser les autres verbes (PUT, DELETE, ...).
Pour une redirection GET, il n'y a aucune différence entre le 302 et le 307. Donc, dans le cas du raccourcisseur d'URL, aucune importance.
Par contre, dans le cas des autres verbes, cela à son importance :
- (client) requête POST vers URL monurl.fr/123soleil => (serveur) réponse HTTP 302 vers bidule.fr/temporary-redirect => (client) requête GET vers URL monurl.fr/123soleil
- (client) requête POST vers URL monurl.fr/123soleil => (serveur) réponse HTTP 307 vers bidule.fr/temporary-redirect => (client) requête POST vers URL monurl.fr/123soleil
Ce besoin provient initialement d'une mécompréhension de la RFC qui défini les verbes HTTP. Normalement, seules les redirections permanentes devaient changer le verbe en GET. Mais beaucoup de clients (les navigateurs par exemple) ont appliqué la même stratégie aux redirections temporaires. Changer cet état de fait aurait créé de nombreux problèmes de compatibilité.
Aussi, il a été décidé de créer un deuxième code d'erreur, le 307, qui fait comme le 302, mais interdiction formel de changer le verbe HTTP.
#5.11
#5.7
À chaque réponse du serveur est associé un de ces codes, dont certains (d'erreur notamment, forcément plus visibles) sont plus ou moins connus, par exemple 404 (not found). Ici, ce sont les codes de redirection (3xx) qui sont utilisés pour envoyer le client tout d'abord depuis le raccourcisseur vers le sitàlacon, puis, dans le cas où c'est un robot qui visite, du sitàlacon vers lemonde.fr.
La différence entre 301 et 302 n'a que peu d'intérêt ici, il suffit de retenir que ce sont des redirections renvoyées par un serveur HTTP qui a tous les éléments pour appliquer la logique détaillée par fdorin plus haut.
#6
Et bien la faculté de l'être humain de pervertir les choses m'émerveillera toujours !
C'est assez ingénieux, un peu comme un lien web avec l'url affichée en texte mais le href différent, on pense aller vers ce qu'on vois mais non.
Mais le pire au final c'est de tromper les outils qui cherchent les cards et les metatags.
Ces bots ne devraient pas suivre les redirections et encore plus quand ce ne sont pas vers les mêmes noms de domaine.
Merci pour le wheregoes effectivement
#7
#7.1
Si X s'occupe de l'aperçu, le site en question ne sait pas qui voit l'aperçu, tant que l'utilisateur n'aura pas cliqué sur le lien (si il clique).
Si X ne s'occupe pas de l'aperçu, mais que c'est un javascript côté client, alors le site en question saura qu'il y a un aperçu. A noter également que l'aperçu côté client poserait sans doute problème d'un point de vue consentement et dépôt des cookies.
De plus, d'un point de vue de X, si c'est X qui gère l'aperçu, il peut optimiser l'affichage (notamment le temps) via une mise en cache, du contenu au moment où il est posté. Chose impossible à faire si le rendu est géré côté client.
Bref, X (ou tout autre site d'ailleurs) a de nombreux intérêts à gérer les aperçus côtés serveur.
L'aperçu de la card à donc
#8
Merci pour le site whereitgoes, je connaissais pas.
#8.1
Si une URL apparait dans un document par exemple, et si l'URL a expiré, alors on a une erreur 404. Mais pire ! Il y a déjà eu des attaques où l'URL raccourcie était réutilisée par des attaquants pour rediriger vers un contenu malveillant ! (certains raccourcisseur d'URL permettent de choisir l'URL générée) On avait donc des documents "officiels" qui pointaient sur des contenus vérolés.