Définition

Comme expliqué sur le site de l’OWASP, le Reverse Tabnabbing est une attaque où une page liée à la page cible est en mesure d’apporter des modifications à cette dernière.

Lors de l’ouverture de la deuxième page (la page malveillante) dans un autre onglet (via l’attribut target=’_blank’), cette dernière est en mesure d’accéder à certaines propriétés de Windows.opener, à savoir :

• Opener.closed : Renvoie une valeur booléenne indiquant si une fenêtre a été fermée ou non.
• Opener.frames : Renvoie tous les éléments iframe de la fenêtre actuelle.
• Opener.length : Renvoie le nombre d’éléments d’iframe dans la fenêtre actuelle.
• Opener.opener : Renvoie une référence à la fenêtre qui a créé la fenêtre.
• Opener.parent : Retourne la fenêtre parente de la fenêtre actuelle
• Opener.self : Retourne la fenêtre actuelle
• Opener.top : Retourne la fenêtre la plus haute du navigateur

S’il s’agit du même domaine, alors le site malveillant est en mesure d’accéder à toutes les propriétés de Windows.opener.

Attaque

Bien qu’à présent, certains palliatifs existent permettant de contrer cette attaque (nous en parlerons un peu plus tard), il reste intéressant de comprendre le fonctionnement de cette attaque et ce qu’il en reste à l’heure actuelle.

Les attaques de type Reverse Tabnabbing sont possibles lorsqu’un utilisateur est en mesure d’insérer une publication contenant un lien sur un site spécifique s’ouvrant dans un nouvel onglet, chose relativement classique sur les réseaux sociaux ou encore les blogs.

De la sorte, le site site-semi-malveillant.fr va s’ouvrir dans un nouvel onglet. Il est important de noter qu’aucun aspect malveillant n’est présent dans ce site, pouvant ainsi gagner la confiance de l’utilisateur et contourner des sandox.

Néanmoins, pendant ce temps-là, l’onglet contenant le réseau social ou le blog d’origine est redirigé vers une mire d’authentification du soi-disant site (https://site-malveillant.fr/login) grâce au code suivant présent sur site-semi-malveillant.fr :

Ainsi, lorsque l’utilisateur en aura fini avec le site semi-malveillant, il pourra reprendre ses activités sur son réseau social initial qui aura changé d’URL et devra se (re)connecter (sur le site malveillant) et ainsi transmettre ses identifiants à un attaquant.

Défense

Plusieurs points sont intéressants à prendre en compte lors de l’aspect défensif du Reverse Tabnabbing qui mit bout à bout pourrait faire office de « Défense en profondeur ».

Défense venant des développeurs

En effet, le premier point se trouve directement au niveau des développeurs du fait qu’il existe ici aussi des meilleures pratiques de sécurité. Ces dernières intègrent la directive rel ayant pour valeur « noopener noreferrer ». La valeur noopener aurait dû être suffisante, mais historiquement, Firefox ne le supportait pas tout le temps, l’ajout des deux est ainsi une valeur sûre :

L’ajout de cette directive permet de renvoyer une valeur nulle à Windows.opener.

Défense venant des navigateurs

De plus, cette vulnérabilité n’étant pas toute récente, les navigateurs ont eu le temps de se mettre à jour et d’intégrer par défaut la protection re=noopener dans la majorité des navigateurs :

À des fins de tests par exemple, il est possible de désactiver temporairement l’utilisation du noopener sur Firefox par le biais de la variable targetBlankNoOpener au sein d’about:config en la passant à False :

Comme il est possible de le voir en affichant le code source de cette page, WordPress a ajouté en mai 2017 (WordPress 4.7.4) cette directive sur l’ensemble des liens ouverts dans un nouvel onglet.

Attention néanmoins, le window.open() n’est pas pris en compte dans cette sécurité par défaut des navigateurs sans l’ajout explicite de la directive noopener.

Défense venant des administrateurs système

Enfin, la dernière possibilité s’offrant à nous est la mise en place d’une Referrer-Policy au sein du serveur applicatif.

Cet en-tête de sécurité permet à un site de contrôler la quantité d’informations que le navigateur inclut lors de la navigation à partir d’un document. La Referrer-Policy peut avoir les valeurs suivantes :

• no-referrer : aucun en-tête referrer n’est envoyée
• no-referrer-when-downgrade : l’en-tête referrer est envoyée si la sécurité de la destination est la même (de HTTPS vers HTTPS)
• same-origin : l’en-tête referrer est envoyée si l’URL a la même origine
• origin : l’en-tête referrer est envoyée, mais contient seulement l’origine (le domaine) et pas l’URL complète
• strict-origin : l’en-tête referrer contient l’origine uniquement (et pas l’URL complète) si la destination est aussi sécurisée (HTTPS vers HTTPS).
• origin-when-cross-origin : l’en-tête referrer contient l’URL complète si la destination a la même origine et contient uniquement l’origine pour les autres cas
• strict-origin-when-cross-origin : l’en-tête referrer contient l’URL complète si la destination a la même origine et contient uniquement l’origine si la destination est aussi sécurisée (HTTPS vers HTTPS).

unsafe-url : l’en-tête referrer contient l’URL complète dans tous les cas