Pourquoi les iframes sont-ils considérés comme dangereux et présentent-ils un risque pour la sécurité ?

Question

Pourquoi les iframes sont-elles considérées comme dangereuses et présentant un risque pour la sécurité? Quelqu'un peut-il décrire un exemple d'un cas où elles peuvent être utilisées de manière malveillante?

Answer 1

L'élément IFRAME peut présenter un risque de sécurité si votre site est intégré à l'intérieur d'un IFRAME sur un site hostile. Cherchez "clickjacking" sur Google pour plus de détails. Notez que cela n'a pas d'importance si vous utilisez </code> ou non. La seule véritable protection contre cette attaque est d'ajouter l'en-tête HTTP <a href="https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/X-Frame-Options" rel="noreferrer"><code>X-Frame-Options: DENY</code></a> et espérer que le navigateur fasse bien son travail.</p> <p>Si quelqu'un affirme que l'utilisation d'un élément <code><iframe></code> sur votre site est dangereuse et peut présenter un risque de sécurité, c'est qu'il ne comprend pas ce qu'est l'élément <code><iframe></code>, ou qu'il parle de la possibilité de vulnérabilités liées à l'élément <code><iframe></code> dans les navigateurs. La sécurité de la balise <code><iframe src="..."></code> est équivalente à celle de <code><img src="..."</code> ou de <code><a href="..."></code> tant qu'il n'y a pas de vulnérabilités dans le navigateur. Et s'il y a une vulnérabilité appropriée, il pourrait être possible de la déclencher même sans utiliser d'élément <code><iframe></code>, <code><img></code> ou <code><a></code>, donc cela ne vaut pas la peine d'être pris en compte pour ce problème.</p> <p>De plus, <strong>l'élément <code>IFRAME</code> peut présenter un risque de sécurité si une page de votre site contient une vulnérabilité XSS qui peut être exploitée</strong>. Dans ce cas, l'attaquant peut étendre l'attaque XSS à n'importe quelle page du même domaine qui peut être convaincue de se charger dans un <code><iframe></code> sur la page présentant la vulnérabilité XSS. Cela est dû au fait que le contenu vulnérable provenant de la même origine (même domaine) à l'intérieur d'un <code><iframe></code> est autorisé à accéder au DOM parent du contenu (pratiquement exécuter du JavaScript dans le document "hôte"). Les seules méthodes de protection réelles contre cette attaque sont d'ajouter l'en-tête HTTP <code>X-Frame-Options: DENY</code> et/ou d'encoder correctement toutes les données soumises par les utilisateurs (c'est-à-dire ne jamais avoir de vulnérabilité XSS sur votre site - plus facile à dire qu'à faire).</p> <p>Cependant, <strong>attention, le contenu de <code><iframe></code> peut lancer une navigation de niveau supérieur par défaut</strong>. C'est-à-dire que le contenu à l'intérieur de l'<code><iframe></code> est autorisé à ouvrir automatiquement un lien sur l'emplacement actuel de la page (le nouvel emplacement sera visible dans la barre d'adresse). La seule façon d'éviter cela est d'ajouter l'attribut <a href="https://caniuse.com/#feat=iframe-sandbox" rel="noreferrer"><code>sandbox</code></a> sans la valeur <code>allow-top-navigation</code>. Par exemple, <code><iframe sandbox="allow-forms allow-scripts" ...></code>. Malheureusement, le bac à sable désactive également tous les plugins, toujours. Par exemple, historiquement, Youtube ne pouvait pas être mis en bac à sable car le lecteur Flash était encore nécessaire pour visualiser tout le contenu de Youtube. Aucun navigateur ne supporte l'utilisation de plugins et l'interdiction de la navigation de niveau supérieur simultanément. Cependant, à moins d'avoir des raisons très spéciales, <strong>vous ne pouvez pas faire confiance à <em>aucun</em> plugin pour fonctionner du tout pour la majorité de vos utilisateurs en 2021</strong>, vous pouvez donc simplement utiliser <code>sandbox</code> toujours et protéger votre site contre les redirections forcées à partir de contenu généré par les utilisateurs également. Notez que cela cassera les contenus mal implémentés qui tentent de modifier <code>document.top.location</code>. Le contenu dans un <code><iframe></code> mis en bac à sable peut toujours ouvrir des liens dans de nouveaux onglets, donc un contenu bien implémenté fonctionnera très bien. Notez également que si vous utilisez <code><iframe sandbox="... allow-scripts allow-same-origin ..." src="blog:..."></code> toute attaque XSS dans le contenu <code>blob:</code> peut être étendue au document hôte car les URL <a href="https://w3c.github.io/FileAPI/#originOfBlobURL" rel="noreferrer"><code>blob:</code> héritent toujours de l'origine de leur document parent</a>. Vous ne pouvez pas envelopper le contenu utilisateur non filtré dans un <code>blob:</code> et le rendre sous forme d'<code><iframe></code> pas plus que vous ne pouvez mettre ce contenu directement sur votre propre page.</p> <p>Une attaque possible se déroule de la manière suivante : supposez que des utilisateurs puissent insérer du contenu généré par l'utilisateur avec un iframe; un <code><iframe></code> sans attribut sandbox peut être utilisé pour exécuter du code JS disant <code>document.top.location.href = ...</code> et forcer une redirection vers une autre page. Si cette redirection se fait vers un site de phishing bien exécuté et que vos utilisateurs ne font pas attention à la barre d'adresse, l'attaquant a de bonnes chances d'obtenir vos utilisateurs à divulguer leurs informations d'identification. Ils ne peuvent pas falsifier la barre d'adresse mais ils peuvent forcer la redirection et contrôler tout le contenu que les utilisateurs peuvent voir par la suite. Omettre <code>allow-top-navigation</code> de la valeur de l'attribut <code>sandbox</code> évite ce problème. Cependant, pour des raisons historiques, les éléments <code><iframe></code> n'ont pas cette limitation par défaut, vous serez donc <strong>plus vulnérable au phishing</strong> si vos utilisateurs peuvent ajouter un élément <code><iframe></code> sans l'attribut <code>sandbox</code>.</p> <p>Notez que <code>X-Frame-Options: DENY</code> protège également contre une attaque de canal secondaire de performance liée au rendu qui peut lire du contenu entre les origines (également connue sous le nom de "<a href="https://www.contextis.com/media/downloads/Pixel_Perfect_Timing_Attacks_with_HTML5_Whitepaper.pdf" rel="noreferrer">Pixel perfect Timing Attacks</a>").</p> <p>Voilà pour le côté technique de la question. <strong>En outre, il y a la question de l'interface utilisateur.</strong> Si vous apprenez à vos utilisateurs à faire confiance au fait que la barre d'adresse ne doit pas changer lorsqu'ils cliquent sur des liens (par exemple, votre site utilise un grand iframe avec tout le contenu réel), alors les utilisateurs ne remarqueront rien à l'avenir en cas de vulnérabilité de sécurité réelle. Par exemple, vous pourriez avoir une vulnérabilité XSS à l'intérieur de votre site qui permet à l'attaquant de charger du contenu d'une source hostile à l'intérieur de votre iframe. Personne ne pourrait faire la différence car la barre d'adresse reste identique au comportement précédent (ne change jamais) et le contenu "semble" valide même s'il provient d'un domaine hostile demandant les informations de connexion de l'utilisateur.</p> <p><strong>Mise à jour année 2023 :</strong></p> <p>La directive Content-Security-Policy (CSP) prend en charge la directive <a href="https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors" rel="noreferrer"><code>frame-ancestors</code></a> qui remplacera l'en-tête de-facto non standard <code>X-Frame-Options: deny</code>.</p> <p>Par conséquent, vous pourriez émettre à la fois <code>X-Frame-Options: deny</code> et <code>Content-Security-Policy: frame-ancestors none</code> pour bloquer les attaques de clickjacking pour les anciens et les nouveaux agents utilisateur / navigateurs internet.</p> <p>En pratique, tous les navigateurs qui ne prennent pas nativement en charge la directive CSP <code>frame-ancestors</code> sont probablement assez anciens pour avoir au moins une vulnérabilité de sécurité critique, donc vous pouvez cesser de diffuser <code>X-Frame-Options: deny</code> si vous définissez une politique pour la directive de l'en-tête <code>Content-Security-Policy</code> <code>frame-ancestors</code>. (Les navigateurs présentant des vulnérabilités critiques ne sont pas sûrs à utiliser, peu importe les en-têtes que vous émettez.)</p></x-turndown>

Answer 2

Dès que vous affichez du contenu à partir d'un autre domaine, vous faites essentiellement confiance à ce domaine pour ne pas diffuser de logiciels malveillants.

Il n'y a rien de mal en soi avec les iframes. Si vous contrôlez le contenu de l'iframe, elles sont parfaitement sûres.

Answer 3

Les IFRAMEs sont acceptables; les légendes urbaines ne le sont pas.

Lorsque vous "utilisez des iframes", cela ne signifie pas une seule chose. Il s'agit d'une ambiguïté lexicale. Selon le cas d'utilisation, "utiliser des iframes" peut signifier l'une des situations suivantes :

1. Quelqu'un d'autre affiche votre contenu dans une iframe
2. Vous affichez le contenu de quelqu'un d'autre dans une iframe
3. Vous affichez votre propre contenu dans une iframe

Alors dans quels cas vous mettez-vous en danger?

1. Quelqu'un d'autre affiche votre contenu

Ce cas est presque toujours appelé clickjacking - imiter le comportement de votre site, en essayant de tromper vos utilisateurs en utilisant une fausse interface utilisateur plutôt que le vrai site. La confusion ici est que votre utilisation ou non d'iframes est sans importance, c'est simplement pas de votre ressort - c'est quelqu'un d'autre qui utilise des iframes, sur lequel vous ne pouvez rien faire. D'ailleurs, ils n'ont même pas besoin d'iframes spécifiquement : ils peuvent copier votre site de toute autre manière, voler votre html, mettre en œuvre un faux site à partir de zéro, etc.

Donc, abandonner les iframes dans le but de prévenir le clickjacking - cela n'a absolument aucun sens.

2. Vous affichez le contenu de quelqu'un d'autre

De ces trois points ci-dessus, c'est le seul qui est un peu risqué, mais la plupart des articles effrayants que vous lisez tout le temps proviennent d'un monde d'avant l'introduction de la politique de même origine. À l'heure actuelle, il n'est toujours pas recommandé d'inclure n'importe quel site dans le vôtre (qui sait ce qu'il contiendra demain ?), mais si c'est une source de confiance (accuweather, info boursière yahoo, etc.), vous pouvez le faire en toute sécurité. Le gros problème ici est de laisser les utilisateurs (par conséquent, les utilisateurs malveillants) contrôler le src de l'iframe, lui disant quoi afficher. Ne laissez pas les utilisateurs charger un contenu arbitraire dans votre page, c'est là que réside tout le mal. Mais c'est vrai avec ou sans les iframes. Cela n'a rien à voir avec eux ; cela pourrait se produire en utilisant une balise script ou un balise style (bonne chance pour vivre sans elles) - le problème c'est que vous les laissez sortir. Toute sortie sur votre site contenant n'importe quel contenu donné par l'utilisateur est RISQUÉE. Sans le nettoyer (éliminer le HTML), vous ouvrez essentiellement votre site aux attaques XSS, n'importe qui peut insérer une balise </code> dans votre contenu, et c'est une mauvaise nouvelle. Genre, très mauvaise nouvelle.</p> <p><em>Ne publiez jamais d'entrée utilisateur sans vous assurer qu'elle est inoffensive.</em></p> <p>Donc, bien que les iframes soient inoffensifs, la leçon à retenir est : ne les faites pas afficher du contenu de tierces parties sauf si vous faites confiance à la source. En d'autres termes, ne incluez pas de contenu non fiable sur votre site. (De plus, ne sautez pas devant un train de marchandises qui arrive rapidement. Logique.)</p> <p><strong>3. Vous affichez votre propre contenu dans une iframe</strong></p> <p>Celui-ci est évidemment sans danger. Votre page est sûre, le contenu interne de l'iframe est sûr, <em>rien ne peut mal tourner</em>. L'iframe n'est pas un tour de magie ; c'est simplement une technique d'encapsulation, vous avez tout à fait le droit d'afficher une partie de votre contenu dans un sandbox. C'est un peu comme le mettre dans un div ou autre chose, seulement il aura son propre environnement de document.</p> <h3>TL;DR</h3> <ul> <li>Cas 1 : peu importe si vous utilisez des iframes ou non,</li> <li>Cas 2 : pas un problème d'iframe,</li> <li>Cas 3 : cas absolument sans danger.</li> </ul> <p>Veuillez cesser de croire aux légendes urbaines. La vérité est que les <code>iframe</code> sont totalement sûrs. Vous pourriez tout aussi bien accuser les balises <code>script</code> d'être dangereuses ; n'importe quoi peut causer des problèmes lorsqu'il est inséré de manière malveillante dans un site. Mais <em>comment</em> l'a-t-on inséré en premier lieu ? Il doit y avoir une vulnérabilité existante du côté serveur si quelqu'un a pu injecter du contenu html dans un site. Accuser une seule technologie pour une attaque commune (au lieu de trouver la vraie cause) est juste un synonyme de maintien des failles de sécurité ouvertes. Trouvez le dragon derrière le feu.</p> <p>Une sortie non nettoyée est mauvaise ; les iframes ne le sont pas.</p> <hr /> <p><strong>MISE À JOUR :</strong><br> Il existe un attribut appelé <em>sandbox</em>, qui vaut la peine d'être vérifié : <a href="https://www.w3schools.com/tags/att_sandbox.asp" rel="nofollow noreferrer">https://www.w3schools.com/tags/att_sandbox.asp</a></p></x-turndown>

Answer 4

Je suppose qu'il s'agit d'un iFrame inter-domaines, car le risque serait sans doute plus faible si vous le contrôliez vous-même.

• Clickjacking est un problème si votre site est inclus dans un iframe
• Un iframe compromis pourrait afficher un contenu malveillant (imaginez l'iframe affichant une boîte de connexion au lieu d'une publicité)
• Un iframe inclus peut effectuer certains appels JS comme alert et prompt, ce qui pourrait ennuyer votre utilisateur
• Un iframe inclus peut rediriger via location.href (ouah, imaginez un iframe tiers rediriger le client de bankofamerica.com vers bankofamerica.fake.com)
• Des logiciels malveillants dans l'iframe tiers (Java/Flash/ActiveX) pourraient infecter votre utilisateur

Answer 5

Les termes "dangereux" et "risque de sécurité" ne sont pas les premières choses qui viennent à l'esprit lorsque les gens mentionnent les iframes ... mais ils peuvent être utilisés dans des attaques de clickjacking.