Tabnabbing et clickjacking : les attaques d'interface que tu ne vois jamais

Ce que fait vraiment le tabnabbing

Un onglet peut se recharger tout seul, même quand il est en arrière-plan. Ce n'est pas une faille, c'est une fonctionnalité voulue du navigateur. Si tu attends la notification d'un nouvel e-mail, il est normal de recevoir l'alerte même quand l'onglet n'est pas au premier plan. Le tabnabbing s'appuie pile sur ce mécanisme.

Voici comment ça se passe. Tu ouvres une page d'apparence anodine, tu la laisses ouverte et tu passes à un autre onglet. Le script de la première page détecte le changement (via la Page Visibility API ou un gestionnaire d'événement focus) et patiente quelques minutes. Ensuite, il remplace le titre, le favicon et tout le HTML de la page. Ce qui était un article ressemble désormais à un écran de connexion Google, Microsoft ou GitHub.

À ton retour, tu tombes sur un écran de connexion qui te semble familier, dans un onglet que tu as ouvert toi-même. Dans la barre d'adresse, l'URL est toujours celle de la page d'origine, mais à peu près personne ne va la vérifier. Le formulaire envoie ce que tu tapes à l'attaquant, puis te redirige vers le vrai Google. Au second essai, tu te dis simplement que la première tentative a foiré.

Clickjacking : un bouton, deux identités

Le clickjacking est une autre ruse d'interface. L'attaquant charge une vraie page (par exemple un écran de changement de mot de passe ou un formulaire « envoyer de l'argent ») dans un iframe invisible, puis la recouvre d'un leurre attirant du genre « clique pour gagner un prix ». L'utilisateur croit cliquer sur le leurre, mais le clic atterrit en fait sur le vrai bouton placé en dessous. Pour le navigateur, ce clic est autorisé, parce que techniquement il l'est.

Le cas d'école, c'est un bouton J'aime de Facebook glissé dans un iframe et recouvert d'un élément de jeu. Sans s'en rendre compte, les victimes likent une page qu'elles n'ont jamais vue. Le scénario devient bien plus sérieux quand le bouton en dessous est le « Confirm » d'un écran de consentement OAuth, ou le « Send transaction » d'une app décentralisée. Les deux ont déjà été exploités en conditions réelles, plus d'une fois.

Sur ce point, ce sont les exploitants de sites qui doivent se protéger. L'en-tête X-Frame-Options et la directive frame-ancestors de la Content-Security-Policy empêchent les autres sites de charger le site de confiance dans un iframe. Les grandes plateformes ont bien verrouillé ça. Les sites qui ne déclarent pas l'en-tête restent attaquables, et les plateformes Web3 récentes ont traîné de vraies lacunes sur ce sujet.

Reverse tabnabbing via window.opener

Une technique cousine s'appelle reverse tabnabbing. Un onglet qui vient d'être ouvert a, via window.opener, accès à la page qui l'a appelé. Si un attaquant arrive à glisser son lien sur ton site, le nouvel onglet peut rediriger la page d'origine de l'intérieur. Plus tard, tu reviens dessus et tu te retrouves sur un clone de phishing du site où tu te trouvais vraiment.

La parade, c'est rel="noopener" sur tous les liens externes, et les navigateurs récents l'appliquent même automatiquement aux liens qui ouvrent un nouvel onglet. Le vecteur classique est ainsi refermé, mais les forums et les sites à contenu généré par les utilisateurs restent vulnérables dès qu'ils rendent les contributions sans assez de précautions.

Pourquoi ces attaques durent

Les attaques d'interface ont trois traits qui les rendent tenaces. D'abord, ce sont le plus souvent de petites entorses à des conventions, pas à des règles techniques. Redessiner un onglet est une capacité légitime du navigateur, embarquer un iframe aussi. Ensuite, elles s'appuient sur des habitudes visuelles et contextuelles que les utilisateurs ne surveillent pas, parce qu'ils n'ont même pas conscience de suivre des conventions.

Enfin, elles ne coûtent presque rien. Un tabnabber, c'est un fichier HTML avec quelques dizaines de lignes de JavaScript. Les attaquants en déploient des dizaines de variantes en parallèle, les combinent avec du malvertising ou du SEO frauduleux, et ne perdent rien quand l'une est repérée.

Ce que tu peux faire aujourd'hui

Les navigateurs et les exploitants de sites portent l'essentiel de la défense. Côté utilisateur, quelques habitudes suffisent à boucher le reste.

1. 1

   Méfie-toi des écrans de connexion dans des onglets inattendus

   Si un onglet réclame d'un coup une connexion à laquelle tu ne t'attendais pas, ferme-le. Rouvre le service depuis un favori.
2. 2

   Vérifie l'URL avant chaque formulaire de connexion

   La barre d'adresse survit au tabnabbing. Une soi-disant page Gmail sur un domaine inconnu saute immédiatement aux yeux.
3. 3

   Garde des sessions courtes

   Plus tes onglets restent ouverts longtemps, plus ils ont l'occasion de se redessiner. Pour les services sensibles, les onglets qui traînent en arrière-plan ne sont vraiment pas une bonne idée.
4. 4

   Effectue les actions critiques dans une session isolée

   Pour donner un consentement OAuth, signer une transaction ou relier des comptes, fais-le dans une session où rien d'autre ne tourne en parallèle. Ça neutralise toutes les ruses d'interface connues, parce qu'aucun second onglet ne peut être manipulé à côté de toi.