Récemment, nous avons écrit sur la sécurité des applications web en ce qui concerne la vulnérabilité XSS. Cette fois-ci, nous voulons attirer votre attention sur un autre danger.

La vulnérabilité dont il est question dans le présent document existe depuis longtemps et, en raison de sa simplicité, elle est souvent sous-estimée, voire inconnue de certains. développeurs d'applications web.

Presque toutes les applications web contiennent des liens qui, lorsqu'on clique dessus, s'ouvrent dans un nouvel onglet afin de ne pas fermer l'onglet avec la page d'origine. Il s'agit d'un comportement privilégié, car les créateurs souhaitent que l'utilisateur passe le plus de temps possible dans l'application.

Une attaque qui exploite cette vulnérabilité est ce qu'on appelle le "reverse tabnabbing". Il s'agit d'une attaque où une page liée à la page cible est capable de remplacer cette page par, par exemple, un site d'hameçonnage.

Scénario d'attaque

1. Supposons que la victime utilise Facebook, qui est connu pour ouvrir des liens via target="_blank",
2. Créer une fausse page virale,
3. Créer un site web de phishing qui ressemble à la page de connexion de Facebook,
4. Mettez le texte ci-dessous code sur la page virale, par exemple, par le biais d'une vulnérabilité XSS trouvée
   window.opener.location = 'https://phishing-website/facebook.com' ;
5. La victime clique sur le lien Facebook menant à la page virale,
6. La page virale redirige l'onglet Facebook vers le site web d'hameçonnage en demandant à l'utilisateur de se reconnecter.

Ainsi, nous pouvons changer l'onglet parent de la page cible infectée par l'objet fenêtre de l'API Web. En général, une attaque consiste à utiliser en parallèle plusieurs vulnérabilités découvertes et des escroqueries par hameçonnage.

Le problème

Lorsque nous ouvrons un nouvel onglet dans le navigateur à l'aide d'un lien avec la balise target="_blank" nous avons accès à notre "référent" depuis le nouvel onglet. Plus précisément, à l'attribut ouvreur de la propriété Fenêtre qui renvoie une référence à la fenêtre qui l'a ouvert, notre page parent.

Ceci est dû au comportement du Fenêtre.open() fonction. En accédant à cet attribut, nous pouvons facilement remplacer notre page parent. Notez que certains navigateurs modernes peuvent rendre window.opener dans l'onglet cible en tant que nul pour éviter ce comportement.

Exemple de code

<code> <a href="https://github.com" target="_blank">Aller sur GitHub - lien infecté</a>
const
 si (lien)
   link[0].onclick = () => {
     if (window) window.opener.location = 'https://stackoverflow.com'
   }

Ci-dessus, vous pouvez voir le lien infecté qui ouvre un nouvel onglet avec une page GitHub, mais entre-temps, il change notre page "parent" en site Stackoverflow.

Exemple concret

1. Liens HTML

Ajouter rel="noopener noreferrer" à la <a> étiquette.

Les rel définit la relation entre une ressource liée et le document actuel.

noopener indique au navigateur de naviguer vers la cible sans autoriser l'accès au parent qui l'a ouverte. Onglet cible Fenêtre.opener sera nul.

noreferrer empêche le navigateur, lorsqu'il navigue vers la cible, d'envoyer au parent l'adresse ou toute autre valeur en tant que référent par l'intermédiaire de l'élément référent En-tête HTTP. Notez que le nom de cet en-tête HTTP est intentionnellement mal orthographié en tant que "referrer".

2. JavaScript liens

Pour le JavaScript Fenêtre.ouverte vous pouvez ajouter les valeurs noopener et noreferrer dans le Caractéristiques de la fenêtre du paramètre Fenêtre.ouverte mais les navigateurs peuvent réagir différemment, c'est pourquoi il est recommandé d'utiliser la fonction Fenêtre.opener comme nul après avoir utilisé Fenêtre.open() fonction.

En savoir plus:

API Rails et CORS. Un soupçon de conscience

Stratégies de récupération des données dans NextJS

7 raisons pour lesquelles votre boutique en ligne a besoin de Magento

Si cet article vous intéresse, suivez Lukasz sur Github : https://github.com/twistezo