Pourquoi les iframes sont-ils considérés comme dangereux et comme un risque pour la sécurité?
125
Pourquoi les iframes sont-ils considérés comme dangereux et comme un risque pour la sécurité? Quelqu'un peut-il décrire un exemple de cas où il peut être utilisé à des fins malveillantes?
@Samich - Non, il s'agit des meilleures pratiques, pas spécifiquement des problèmes de sécurité (et le seul problème de sécurité auquel je puisse penser provient de tiers utilisant des iframes)
Quentin
Pas tant la sécurité que ce n'est pas considéré comme une meilleure pratique, voir: stackoverflow.com/questions/1081315/why-developers-hate-iframes Ils étaient beaucoup plus populaires lorsque les gens concevaient également avec des tables, des divs, mais éliminaient tout le besoin d'iframes.
RandomUs1r
Curieusement, un article est apparu près d'une décennie plus tard, suggérant que mettre tout ce qui contient un formulaire dans une iframe, isolé de tous vos javascript tiers, etc., est peut-être nécessaire pour protéger les formulaires contre la récolte. hackernoon.com
GordonM
Réponses:
84
Dès que vous affichez du contenu 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, ils sont parfaitement sûrs.
Dès que vous créez un lien vers du contenu d'un autre domaine, etc., il n'y a rien de spécifique à ce sujet.
Quentin
5
Un navigateur correctement implémenté (aka User Agent) ne permettra pas au contenu de l'iframe de s'échapper en dehors de l'iframe. Si le document hôte (celui contenant l' <iframe>élément) a un style approprié et indique que l'iframe contient un contenu non approuvé, il n'y a pas de problème. Modulo de vraies vulnérabilités dans le navigateur, bien sûr. En bref, un <iframe>est à peu près aussi sûr qu'un <a href>.
Mikko Rantalainen
2
Qu'en est-il d'une iframe cachée qui appartient au même domaine? Est-ce totalement sûr?
Ciaran Gallagher
2
Caché <iframe>dans le même domaine peut entraîner des risques de sécurité si le contenu à l'intérieur de l'iframe caché peut être modifié par un attaquant. Cela permettra à l'attaquant d'étendre l'attaque XSS à l'intérieur du caché <iframe>à n'importe quelle page de votre site qui fait référence audit <iframe>contenu. Voir stackoverflow.com/a/9428051/334451 pour plus de détails.
Mikko Rantalainen
Fait intéressant, un iFrame pourrait en fait être une protection utile contre le cas inverse. Si vous avez beaucoup de scripts tiers sur votre site, vous devez en isoler les formulaires. Une manière suggérée de le faire était de placer le formulaire dans sa propre page minimale sans JavaScript tiers et de l'afficher dans un iframe dans la page hôte. hackernoon.com
GordonM
140
L' IFRAMEélément peut constituer un risque pour la sécurité si votre site est intégré à l'intérieur d'un IFRAMEsite hostile . Google "clickjacking" pour plus de détails. Notez que peu importe que vous l' utilisiez <iframe>ou non. La seule vraie protection contre cette attaque est d'ajouter un en-tête HTTP X-Frame-Options: DENYet d'espérer que le navigateur connaît son travail.
De plus, l' élément IFRAME peut être un risque de sécurité si une page de votre site contient une vulnérabilité XSS qui pourrait être exploitée . Dans ce cas, l'attaquant peut étendre l'attaque XSS à n'importe quelle page du même domaine qui peut être persuadée de se charger dans une <iframe>sur la page avec une vulnérabilité XSS. En effet, le contenu de la même origine (même domaine) est autorisé à accéder au DOM du contenu parent (pratiquement exécuter JavaScript dans le document «hôte»). La seule véritable méthode de protection contre cette attaque est d'ajouter un en-tête HTTP X-Frame-Options: DENYet / ou de toujours encoder correctement toutes les données soumises par l'utilisateur (c'est-à-dire de ne jamais avoir de vulnérabilité XSS sur votre site - plus facile à dire qu'à faire).
C'est l'aspect technique du problème. De plus, il y a le problème 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 une grande iframe avec tout le contenu réel), alors les utilisateurs ne remarqueront rien à l'avenir non plus en cas de sécurité réelle vulnérabilité. Par exemple, vous pourriez avoir une vulnérabilité XSS dans votre site qui permet à l'attaquant de charger du contenu à partir d'une source hostile dans votre iframe. Personne ne pouvait faire la différence car la barre d'URL a toujours l'air 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 d'identification de l'utilisateur.
Si quelqu'un prétend que l'utilisation d'un <iframe>élément sur votre site est dangereux et entraîne un risque pour la sécurité, il ne comprend pas ce que fait l' <iframe>élément, ou il parle de la possibilité de <iframe>vulnérabilités associées dans les navigateurs. La sécurité du <iframe src="...">tag est égale <img src="..."ou <a href="...">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 déclencher même sans utiliser <iframe>, <img>ou <a>élément, il est donc pas utile d' envisager pour cette question.
Cependant, sachez que le contenu de <iframe>peut lancer la navigation de niveau supérieur par défaut . Autrement dit, le contenu de <iframe>est autorisé à ouvrir automatiquement un lien sur l'emplacement actuel de la page (le nouvel emplacement sera visible dans la barre d'adresse). Le seul moyen d'éviter cela est d'ajouter un sandboxattribut sans valeur allow-top-navigation. Par exemple <iframe sandbox="allow-forms allow-scripts" ...>,. Malheureusement, sandbox désactive également tous les plugins, toujours. Par exemple, le contenu Youtube ne peut pas être mis en bac à sable car Flash Player est toujours nécessaire pour afficher tout le contenu Youtube. Aucun navigateur ne prend en charge l'utilisation de plugins et l'interdiction de la navigation de haut niveau en même temps.
Notez que cela X-Frame-Options: DENYprotège également contre les performances de rendu des attaques de canal latéral qui peuvent lire le contenu d'origine croisée (également connu sous le nom de « Pixel perfect Timing Attacks »).
Bien, mais ne devrait pas "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."être reformulé dans le sens du document (parent) contenant une vulnérabilité XSS au document (enfant) dans l'iframe?
Shuzheng le
@Shuzheng la vulnérabilité va dans les deux sens et si vous l'utilisez <iframe>sur une page, elle permet d'étendre la vulnérabilité du contenu de l'iframe au document hôte. La question était d' <iframe>être dangereux et si le document hôte a une vulnérabilité XSS, vous n'avez vraiment pas besoin de l' <iframe>élément.
Mikko Rantalainen le
13
Je suppose que l'iFrame inter-domaines est vraisemblablement plus faible si vous le contrôliez vous-même.
Le détournement de clic est un problème si votre site est inclus en tant qu'iframe
Un iFrame compromis pourrait afficher du contenu malveillant (imaginez que l'iFrame affiche une boîte de connexion au lieu d'une annonce)
Un iframe inclus peut effectuer certains appels JS comme l'alerte et l'invite, ce qui pourrait ennuyer votre utilisateur
Un iframe inclus peut rediriger via location.href (yikes, imaginez un cadre 3p redirigeant le client de bankofamerica.com vers bankofamerica.fake.com)
Les logiciels malveillants à l'intérieur du cadre 3p (java / flash / activeX) peuvent infecter votre utilisateur
«Dangereux» et «Risque de sécurité» ne sont pas les premières choses qui viennent à l'esprit lorsque les gens mentionnent des iframes… mais ils peuvent être utilisés dans des attaques de détournement de clic .
Réponses:
Dès que vous affichez du contenu 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, ils sont parfaitement sûrs.
la source
<iframe>élément) a un style approprié et indique que l'iframe contient un contenu non approuvé, il n'y a pas de problème. Modulo de vraies vulnérabilités dans le navigateur, bien sûr. En bref, un<iframe>est à peu près aussi sûr qu'un<a href>.<iframe>dans le même domaine peut entraîner des risques de sécurité si le contenu à l'intérieur de l'iframe caché peut être modifié par un attaquant. Cela permettra à l'attaquant d'étendre l'attaque XSS à l'intérieur du caché<iframe>à n'importe quelle page de votre site qui fait référence audit<iframe>contenu. Voir stackoverflow.com/a/9428051/334451 pour plus de détails.L'
IFRAMEélément peut constituer un risque pour la sécurité si votre site est intégré à l'intérieur d'unIFRAMEsite hostile . Google "clickjacking" pour plus de détails. Notez que peu importe que vous l' utilisiez<iframe>ou non. La seule vraie protection contre cette attaque est d'ajouter un en-tête HTTPX-Frame-Options: DENYet d'espérer que le navigateur connaît son travail.De plus, l' élément IFRAME peut être un risque de sécurité si une page de votre site contient une vulnérabilité XSS qui pourrait être exploitée . Dans ce cas, l'attaquant peut étendre l'attaque XSS à n'importe quelle page du même domaine qui peut être persuadée de se charger dans une
<iframe>sur la page avec une vulnérabilité XSS. En effet, le contenu de la même origine (même domaine) est autorisé à accéder au DOM du contenu parent (pratiquement exécuter JavaScript dans le document «hôte»). La seule véritable méthode de protection contre cette attaque est d'ajouter un en-tête HTTPX-Frame-Options: DENYet / ou de toujours encoder correctement toutes les données soumises par l'utilisateur (c'est-à-dire de ne jamais avoir de vulnérabilité XSS sur votre site - plus facile à dire qu'à faire).C'est l'aspect technique du problème. De plus, il y a le problème 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 une grande iframe avec tout le contenu réel), alors les utilisateurs ne remarqueront rien à l'avenir non plus en cas de sécurité réelle vulnérabilité. Par exemple, vous pourriez avoir une vulnérabilité XSS dans votre site qui permet à l'attaquant de charger du contenu à partir d'une source hostile dans votre iframe. Personne ne pouvait faire la différence car la barre d'URL a toujours l'air 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 d'identification de l'utilisateur.
Si quelqu'un prétend que l'utilisation d'un
<iframe>élément sur votre site est dangereux et entraîne un risque pour la sécurité, il ne comprend pas ce que fait l'<iframe>élément, ou il parle de la possibilité de<iframe>vulnérabilités associées dans les navigateurs. La sécurité du<iframe src="...">tag est égale<img src="..."ou<a href="...">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 déclencher même sans utiliser<iframe>,<img>ou<a>élément, il est donc pas utile d' envisager pour cette question.Cependant, sachez que le contenu de
<iframe>peut lancer la navigation de niveau supérieur par défaut . Autrement dit, le contenu de<iframe>est autorisé à ouvrir automatiquement un lien sur l'emplacement actuel de la page (le nouvel emplacement sera visible dans la barre d'adresse). Le seul moyen d'éviter cela est d'ajouter unsandboxattribut sans valeurallow-top-navigation. Par exemple<iframe sandbox="allow-forms allow-scripts" ...>,. Malheureusement, sandbox désactive également tous les plugins, toujours. Par exemple, le contenu Youtube ne peut pas être mis en bac à sable car Flash Player est toujours nécessaire pour afficher tout le contenu Youtube. Aucun navigateur ne prend en charge l'utilisation de plugins et l'interdiction de la navigation de haut niveau en même temps.Notez que cela
X-Frame-Options: DENYprotège également contre les performances de rendu des attaques de canal latéral qui peuvent lire le contenu d'origine croisée (également connu sous le nom de « Pixel perfect Timing Attacks »).la source
"This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."être reformulé dans le sens du document (parent) contenant une vulnérabilité XSS au document (enfant) dans l'iframe?<iframe>sur une page, elle permet d'étendre la vulnérabilité du contenu de l'iframe au document hôte. La question était d'<iframe>être dangereux et si le document hôte a une vulnérabilité XSS, vous n'avez vraiment pas besoin de l'<iframe>élément.Je suppose que l'iFrame inter-domaines est vraisemblablement plus faible si vous le contrôliez vous-même.
la source
«Dangereux» et «Risque de sécurité» ne sont pas les premières choses qui viennent à l'esprit lorsque les gens mentionnent des iframes… mais ils peuvent être utilisés dans des attaques de détournement de clic .
la source
iframe est également vulnérable au Cross Frame Scripting:
la source