Pourquoi les iframes sont-elles considérées comme dangereuses et comme un risque pour la sécurité ?

Question

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

Answer 1

El IFRAME peut constituer un risque pour la sécurité si votre site est intégré dans un IFRAME sur un site hostile . Google "clickjacking" pour plus de détails. Notez que cela n'a pas d'importance si usted utiliser <iframe> ou pas. La seule véritable protection contre cette attaque consiste à ajouter un en-tête HTTP X-Frame-Options: DENY et espérer que le navigateur fasse son travail.

Si quelqu'un prétend que l'utilisation d'un <iframe> sur votre site est dangereux et présente un risque pour la sécurité, ils ne comprennent pas ce qu'il faut faire. <iframe> élément, ou ils parlent de la possibilité de <iframe> les vulnérabilités liées aux navigateurs. Sécurité de <iframe src="..."> est égal à <img src="..." o <a href="..."> tant qu'il n'y a pas de vulnérabilité dans le navigateur. Et s'il existe une vulnérabilité appropriée, il peut être possible de la déclencher même sans utiliser l'option <iframe> , <img> o <a> Il n'est donc pas utile de l'envisager pour ce problème.

En outre, L'élément IFRAME peut présenter un risque pour la sécurité si une page de votre site contient une vulnérabilité XSS qui peut être exploitée. . Dans ce cas, l'attaquant peut étendre l'attaque XSS à toute page du même domaine qui peut être persuadée de se charger dans un délai d'un an. <iframe> sur la page présentant une vulnérabilité XSS. Cela est dû au fait que le contenu vulnérable provenant de la même origine (même domaine) dans la page <iframe> est autorisé à accéder au DOM du contenu parent (pratiquement à exécuter du JavaScript dans le document "hôte"). La seule véritable méthode de protection contre cette attaque consiste à ajouter un en-tête HTTP X-Frame-Options: DENY et/ou toujours coder 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).

Cependant, veuillez noter que le contenu de <iframe> peut lancer la navigation de premier niveau par défaut . C'est-à-dire que le contenu du <iframe> permet d'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 sandbox attribut sans valeur allow-top-navigation . Par exemple, <iframe sandbox="allow-forms allow-scripts" ...> . Malheureusement, le bac à sable désactive également tous les plugins, toujours. Par exemple, historiquement, Youtube ne pouvait pas être sandboxé parce que le lecteur Flash était toujours nécessaire pour visualiser tout le contenu de Youtube. Aucun navigateur ne permet d'utiliser des plugins et de désactiver la navigation de haut niveau en même temps. Cependant, à moins que vous n'ayez des raisons très particulières, vous ne pouvez pas faire confiance tout pour que les plugins fonctionnent pour la majorité de vos utilisateurs en 2021. donc vous pouvez simplement utiliser sandbox toujours et protégez également votre site contre les redirections forcées provenant de contenus générés par les utilisateurs. Notez que cela brisera le contenu mal implémenté qui tente de modifier document.top.location . Le contenu dans le bac à sable <iframe> peuvent toujours ouvrir des liens dans de nouveaux onglets. Un contenu bien mis en œuvre fonctionnera donc très bien. Notez également que si vous utilisez <iframe sandbox="... allow-scripts allow-same-origin ..." src="blog:..."> toute attaque XSS au sein de l blob: le contenu peut être étendu au document hôte car blob: Les URLs héritent toujours de l'origine de leur document parent. . Vous ne pouvez pas envelopper du contenu utilisateur non filtré dans des blob: et le rendre comme un <iframe> pas plus que vous ne pouvez mettre ce contenu directement sur votre propre page.

Voici un exemple d'attaque : supposons que les utilisateurs puissent insérer du contenu généré par l'utilisateur à l'aide d'un iframe ; un <iframe> sans un attribut sandbox peut être utilisé pour exécuter du code JS disant document.top.location.href = ... et forcer une redirection vers une autre page. Si cette redirection mène à un site de phishing bien exécuté et que vos utilisateurs ne font pas attention à la barre d'adresse, l'attaquant a une bonne chance d'amener vos utilisateurs à divulguer leurs informations d'identification. Ils ne peuvent pas truquer la barre d'adresse, mais ils peuvent forcer la redirection et contrôler tout le contenu que les utilisateurs peuvent voir par la suite. Quitter allow-top-navigation de sandbox permet d'éviter ce problème. Cependant, pour des raisons historiques, <iframe> n'ont pas cette limitation par défaut, donc vous serez plus vulnérables au phishing si vos utilisateurs peuvent ajouter <iframe> élément sans attribut sandbox .

Notez que X-Frame-Options: DENY protège également les performances de rendu contre les attaques par canal latéral qui peuvent lire le contenu de manière croisée (également connues sous le nom de " Attaques de timing parfaites au pixel près ").

C'est le côté technique de la question. En outre, il y a la question de l'interface utilisateur. Si vous apprenez à vos utilisateurs à croire que la barre d'URL est censée ne 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, même en cas de vulnérabilité réelle de la sécurité. Par exemple, vous pourriez avoir une vulnérabilité XSS dans votre site qui permet à l'attaquant de charger du contenu d'une source hostile dans votre iframe. Personne ne pourrait faire la différence car la barre d'URL reste identique au comportement précédent (elle ne change jamais) et le contenu "semble" valide même s'il provient d'un domaine hostile et demande les informations d'identification de l'utilisateur.

Answer 2

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

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

Answer 3

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

Lorsque vous "utilisez des iframes", cela ne veut pas dire 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 un iframe.
3. Vous affichez votre propre contenu dans une iframe.

Alors, lesquels de ces cas peuvent vous mettre en danger ?

1. Quelqu'un d'autre affiche votre contenu

Ce cas est presque toujours désigné comme clickjacking - imiter le comportement de votre site, en essayant d'inciter vos utilisateurs à utiliser une fausse interface utilisateur au lieu du vrai site. Le malentendu ici est que vous utilisez ou non des iframes n'est pas pertinent, ce n'est tout simplement pas à vous de décider - c'est à vous de décider. quelqu'un d'autre utilise des iframes et vous ne pouvez rien y faire. D'ailleurs, ils n'en ont pas besoin : ils peuvent copier votre site d'une autre manière, en volant votre code html, en créant un faux site à partir de rien, etc.

L'abandon des iframes pour tenter d'empêcher le clickjacking n'a donc aucun sens.

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

Des trois ci-dessus, c'est le seul qui est un peu risqué mais la plupart des articles effrayants que vous lisez tout le temps viennent d'un monde d'avant politique d'origine commune a été introduit. À 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 s'il s'agit d'une source fiable (accuweather, yahoo stock info, etc.), vous pouvez le faire en toute sécurité. Le grand non-non ici est de laisser les utilisateurs (donc, les utilisateurs malveillants) contrôler le site de src de l'iframe, lui indiquant ce qu'il doit afficher. Ne laissez pas les utilisateurs charger un contenu arbitraire dans votre page c'est la racine de tout mal. Mais c'est vrai. avec ou sans iframes. Cela n'a rien à voir avec eux ; cela peut arriver en utilisant une script ou un style tag (bonne chance pour vivre sans eux) - le problème est que vous les laissez sortir. Toute sortie sur votre site contenant un contenu donné par l'utilisateur est RISQUÉE. Si vous ne l'aseptisez pas (en le dé-humanisant), vous ouvrez votre site aux attaques XSS. <script> dans votre contenu, et c'est une mauvaise nouvelle. Genre, une baaa mauvaise nouvelle.

N'éditez jamais une entrée utilisateur sans vous assurer qu'elle est inoffensive.

Ainsi, bien que les iframes soient à nouveau innocentes, la leçon à retenir est la suivante : ne les faites pas afficher du contenu tiers, sauf si vous avez confiance en la source. En d'autres termes, n'incluez pas de contenu non fiable dans votre site. (De même, ne vous jetez pas devant les trains de marchandises qui approchent à toute vitesse).

3. Vous affichez votre propre contenu dans une iframe.

Celui-ci est évidemment inoffensif. Votre page est fiable, le contenu interne de l'iframe est fiable, rien ne peut aller mal . Iframe n'est pas un tour de magie, c'est juste une technique d'encapsulation. Vous avez absolument le droit de montrer une partie de votre contenu dans un bac à sable. C'est un peu comme si vous le mettiez à l'intérieur d'un div ou de n'importe quoi d'autre, mais il aura son propre environnement de document.

TL;DR

• Cas 1 : peu importe que vous utilisiez des iframes ou non,
• Cas 2 : pas un problème d'iframe,
• Cas 3 : cas absolument inoffensif.

Arrêtez de croire aux légendes urbaines. La vérité est que, iframe -sont totalement sûrs. Vous pourriez aussi bien accuser script des balises pour leur dangerosité ; tout peut causer des problèmes lorsqu'il est inséré de manière malveillante dans un site. Mais comment l'ont-ils inséré en premier lieu ? Il doit y avoir une vulnérabilité dorsale existante si quelqu'un a pu injecter du contenu html dans un site. Blâmer un élément de technologie pour une attaque commune (au lieu de trouver la cause réelle) n'est qu'un synonyme pour garder les failles de sécurité ouvertes. Trouvez le dragon derrière le feu.

Les sorties non numérisées sont mauvaises, les iframes ne le sont pas.
Arrêtez la chasse aux sorcières.

---

UPDATE :
Il existe un attribut appelé bac à sable qui vaut la peine d'être vérifiée : https://www.w3schools.com/tags/att_sandbox.asp

UPDATE 2 :
Avant de vous prononcer contre les iframes, pensez aux marteaux. Les marteaux sont dangereux. Ils ne sont pas non plus très beaux, il est difficile de nager avec, c'est mauvais pour les dents, et un type dans un film a une fois mal utilisé un marteau, causant de graves blessures. De plus, je viens de faire une recherche sur Google et des tonnes de documents disent que les mortels ne peuvent même pas les déplacer. Si cela ressemble à une bonne raison de ne plus jamais utiliser un marteau, les iframes ne sont peut-être pas votre véritable ennemi. Désolé de m'être égaré.

Answer 4

Je suppose qu'il s'agit d'une iFrame inter-domaine, puisque le risque est probablement moindre si vous la contrôlez vous-même.

• Clickjacking est un problème si votre site est inclus dans une iframe.
• Une iFrame compromise pourrait afficher un contenu malveillant (imaginez que l'iFrame affiche une boîte de connexion au lieu d'une publicité).
• Une iframe incluse peut effectuer certains appels JS comme alert et prompt, ce qui peut gêner votre utilisateur.
• Une iframe incluse peut rediriger via location.href (aïe, imaginez une frame 3p redirigeant le client de bankofamerica.com vers bankofamerica.fake.com)
• Les logiciels malveillants contenus dans le cadre 3p (java/flash/activeX) peuvent infecter votre utilisateur.

Answer 5

Les termes "dangereux" et "risque pour la sécurité" ne sont pas les premières choses qui viennent à l'esprit lorsqu'on évoque les iframes mais ils peuvent être utilisés dans les domaines suivants clickjacking attaques.