Onglets trompeurs et clics détournés : comment l'interface peut t'induire en erreur

Comment un onglet change d'apparence

Une page peut modifier son propre contenu, son titre et son icône après son chargement. Elle peut aussi savoir si son onglet est visible grâce à l'API Page Visibility. Ces capacités servent à des fonctions web ordinaires, mais une page malveillante peut s'en servir pour imiter un service auquel tu fais confiance.

Voici un scénario possible : tu ouvres une page contrôlée ou compromise par un attaquant, puis tu passes à un autre onglet. Son script détecte qu'elle est en arrière-plan et affiche ensuite un faux écran de connexion. Elle peut remplacer son propre HTML et son icône, mais pas la véritable origine affichée dans la barre d'adresse. Le moment et l'apparence du changement dépendent du code de l'attaquant ; il n'y a pas de délai fixe.

Si tu saisis un mot de passe ou un code à usage unique dans ce formulaire, la page peut l'envoyer à l'attaquant, puis te rediriger vers le vrai service pour rendre la manœuvre moins visible. Vérifie la barre d'adresse avant de saisir des identifiants, surtout si un onglet te demande soudain de te connecter. Une clé d'accès liée à l'origine authentique peut résister à ce type de collecte d'identifiants sur un faux site.

Détourner un clic avec une page intégrée

Pour détourner un clic, l'attaquant intègre un site légitime dans un cadre sur sa propre page et dispose un leurre de façon que le clic atteigne une commande de la page intégrée. Encore faut-il que le site cible autorise cette intégration et que la commande soit accessible dans l'état actuel du compte. MDN illustre le mécanisme. Cela ne donne pas un accès arbitraire à tous les comptes ou à toutes les transactions.

L'exemple classique est un bouton de réseau social caché sous un élément de jeu, que l'utilisateur clique sans le vouloir. Les conséquences dépendent de ce que permet la page intégrée. Les actions sensibles peuvent exiger une nouvelle confirmation, et les règles de cookies entre sites peuvent empêcher le cadre d'accéder à la session ouverte de l'utilisateur. Un écran d'autorisation ou de paiement n'est pas forcément intégrable simplement parce qu'il comporte un bouton.

La protection principale relève des sites. La directive CSP frame-ancestors limite les sites autorisés à intégrer une page ; X-Frame-Options fournit une restriction plus simple pour les anciens navigateurs. Un site qui doit permettre l'intégration peut n'autoriser que des pages parentes de confiance et demander une confirmation pour les actions importantes. L'absence de restriction peut créer une ouverture, mais l'exploitabilité dépend de la page et de ses autres défenses.

Quand window.opener entre en jeu

Le tabnabbing inversé dépend d'un lien entre la nouvelle fenêtre et celle qui l'a ouverte. Si une page ouvre une autre fenêtre en laissant window.opener disponible, la page ouverte peut parfois rediriger la première vers un site d'hameçonnage. Les règles entre origines empêchent la lecture du contenu de la première page, mais peuvent encore autoriser sa navigation, comme l'explique MDN.

Les liens modernes avec target="_blank" se comportent par défaut comme s'ils avaient rel="noopener" : window.opener reste nul sauf si le lien demande explicitement le contraire. MDN documente ce comportement. Les scripts qui utilisent window.open() devraient tout de même demander noopener lorsque c'est approprié. Un lien vers un site non fiable ne présente donc pas automatiquement ce risque.

Les conditions nécessaires à ces attaques

Ces attaques détournent des fonctions web ordinaires. Une page peut changer d'apparence, et certains sites autorisent volontairement leur intégration dans d'autres pages. Le risque dépend de l'origine de la page, de sa politique d'intégration, de l'état du compte et de l'action suivante de l'utilisateur. Une apparence familière ne prouve pas qu'une page appartient au service qu'elle imite.

Les réglages par défaut des navigateurs ont fermé certaines failles anciennes, notamment le lien habituel entre deux onglets. Les sites doivent encore définir des règles d'intégration adaptées, et les utilisateurs vérifier l'origine avant de se connecter ou de valider une action. Le guide OWASP sur le détournement de clic évoque aussi les cookies SameSite et les étapes de confirmation comme protections supplémentaires. Aucun réflexe ni en-tête HTTP ne suffit à lui seul contre toutes les tromperies d'interface.

Protections utiles aux visiteurs et aux sites

Appuie-toi sur les protections du navigateur et du site, puis vérifie la page avant d'agir.

1. 1

   Vérifie les demandes de connexion inattendues

   Si un onglet te demande soudain de te connecter, regarde son adresse. En cas de doute, ouvre le service séparément depuis un favori fiable ou une adresse saisie toi-même.
2. 2

   Contrôle l'origine, pas seulement l'apparence

   La barre d'adresse indique où se trouve réellement l'onglet. Un domaine ressemblant au bon n'est pas le service que tu voulais utiliser. Quand elles sont disponibles, les clés d'accès liées à la bonne origine réduisent aussi le risque de voler des identifiants sur un faux site.
3. 3

   Vérifie le contexte des actions importantes

   Avant d'autoriser un accès ou un paiement, vérifie quel site fait la demande et quelle action il décrit. Les exploitants doivent limiter l'intégration des pages sensibles et prévoir une confirmation adaptée.
4. 4

   Utilise l'isolation pour ce qu'elle sépare

   Une session Browser.lol peut isoler les contenus web de ton navigateur local. Elle ne certifie pas l'apparence d'une page et n'empêche pas une page malveillante dans le navigateur distant de changer d'aspect ou d'utiliser un cadre autorisé. Vérifie aussi là-bas l'origine et l'action demandée.