Pourquoi les iframes sont-ils autorisés dans les navigateurs modernes?
J'ai lu un certain nombre de blogs sur la sécurité informatique (bien que je ne sois pas un expert en sécurité), et il semble qu'un pourcentage significatif d'exploits dans la nature soit livré en ajoutant des iframes malveillants à un site Web piraté, l'iframe pointant vers la charge utile malveillante.
Compte tenu de cela, ainsi que du fait que je n'ai vraiment vu pratiquement aucune application iframe légitime qui ne soit pas désagréable, pourquoi est-elle autorisée dans les navigateurs modernes? Il me semble qu'un moyen simple de bloquer un nombre important d'attaques au volant serait de simplement désactiver la prise en charge des iframes dans le navigateur.
Alternativement, un mécanisme "click-to-load", similaire aux plugins "click-to-flash" communs à de nombreux navigateurs aurait un effet similaire, sans empêcher complètement les sites existants qui utilisent des iframes de fonctionner.
Alternativement, interdire les iframes qui chargent du contenu à partir d'un autre domaine serait probablement également efficace.
Je ne prétends certainement pas que le blocage des iframes résoudrait toutes les solutions de sécurité Web, mais d'un point de vue coût-avantage, cela semble être un moyen très simple de contourner un nombre important de problèmes de sécurité.
Étant donné que le cadrage est obsolète et que AJAX a le contrôle Origin, les iframes sont à peu près le seul moyen d'incorporer une autre page dans la vôtre.
Une autre chose est que vous pouvez utiliser des iframes pour afficher des PDF/etc. Bien sûr, vous pouvez utiliser <object> pour cela aussi, mais les iframes sont plus faciles.
GMail est fabriqué à partir d'iframes. L'UX fluide de GMail (vous pouvez toujours l'utiliser lorsque votre connexion Internet est interrompue, une navigation fluide sans avoir à recharger à chaque fois) provient des iframes. Encore une fois, cela pourrait être implémenté dans AJAX, mais c'est plus difficile.
Une dernière chose qui me vient à l'esprit est la compatibilité descendante. De nombreux sites utilisent des iframes, et leur désactivation en briserait trop. Bien sûr, cliquer pour activer ne le coupera pas ici non plus. L'un des précurseurs de AJAX était une astuce avec les iframes et le javascript. Beaucoup de sites Web utilisaient cela, et "cliquer pour charger" interrompra le flux du JS.
D'un autre côté, les problèmes avec les iframes (CSRF, clickjacking, etc.) sont bien connus des développeurs modernes et ils peuvent prendre des mesures pour éviter cela.
Si vous le regardez, les arguments de cette question pourraient être également appliqués à Java. Ou Flash. Ou PDF incorporé. Ou images (CSRF). Ou des cookies. Par exemple, d'autres sites peuvent vous CSRF via des images. C'est à vous de vous assurer que votre site n'est pas vulnérable à ceux-ci.
-D Secure les systèmes de paiement (par exemple MasterCard SecureCode ) utilisent un iframe. Les versions précédentes utilisaient une fenêtre contextuelle, dont la provenance pouvait être vérifiée beaucoup plus facilement par l'utilisateur. Il s'est avéré apparemment que les utilisateurs auxquels une popup de VISA/MasterCard est présentée ne vérifient pas, en fait, la provenance de la popup; au lieu de cela, il devient confus et renonce, abandonnant sa transaction.
On peut en tirer la conclusion suivante: les iframes ne disparaîtront pas de sitôt. Ils sont désormais nécessaires pour une compatibilité descendante avec les systèmes de paiement qui, en fin de compte, paient pour l'ensemble de l'Internet. De plus, nous pouvons dire que ne pas utiliser des iframes n'apporte des avantages de sécurité que dans la mesure où les utilisateurs activent leur cerveau et ne paniquent pas - je ne parierais pas là-dessus .
Interdire les iframes briserait la fonctionnalité et ne donnerait rien.
L'injection d'exploit se fait généralement avec un iframe car c'est le moyen le plus pratique pour les attaquants de configurer et de gérer la redirection. Mais les iframes réels n'ont rien à voir avec les exploits. Ce n'est pas comme Click-to-Play où vous êtes protégé contre les exploits réels dans les plugins Java et Flash directement.
Si seuls quelques utilisateurs ont désactivé les iframes, ils bénéficient d'un avantage en termes de sécurité en évitant ces attaques. (Bien que, étant donné que les iframes sont largement utilisés pour de nombreux types de fonctionnalités sur le Web, il est douteux que cela en vaille la peine.)
Mais si chaque navigateur désactivait la prise en charge d'iframe, les attaquants choisiraient simplement une autre méthode pour injecter des exploits dans des sites compromis, tels que _ <script>, redirection de page, fenêtres contextuelles, etc.
Une mesure de sécurité qui résout des symptômes tels que <iframe> au lieu de la cause première du problème n'est utile que s'il est inhabituel, afin que les attaquants ne s'y attendent pas. Dès qu'il devient courant, il perd sa valeur. Si vous êtes un fournisseur majeur de navigateurs, il est inutile d'implémenter un contrôle de sécurité qui se rendra immédiatement inutile.
Le World Wide Web est une collection de ressources liées. Le iframe est l'éditeur de liens ultime, il relie à des ensembles entiers de ressources. Et comme toute technologie, elle peut être utilisée pour le bien et pour le mal.
iframe n'est pas le seul moyen de créer un lien vers des ressources de logiciels malveillants. En fin de compte, il existe un script JavaScript ou une autre ressource comme un SWF ou un JAR qui exploite le navigateur. Le iframe est juste un moyen agréable, flexible et compact de gérer le chargement de contenu malveillant à partir de sources centralisées.
Noscript a le type de contrôles qui block iframes . Il est désactivé par défaut car il casse beaucoup de choses. Une grande partie de la technologie Web est basée sur le iframe et beaucoup d'Internet se briserait si vous bloquiez ou demandiez iframes.
Le iframe est juste un élément qui permet de mélanger le contenu de différentes sources vers un seul client. Il y a d'autres éléments comme celui-ci. Si vous interdisez les éléments iframe, les mêmes risques de sécurité subsisteront, avec des animations Flash par exemple. Dans un élément object ou embed, un site A affichant des publicités Flash permet à un site B de décider quel contenu sera affiché aux utilisateurs du site A. Les animations Flash peuvent exécuter des scripts, accéder à des micro- stockage… Les risques intersites sont donc là.
99% des vidéos sont présentées dans des iframes - y compris Youtube, vimeo, Vk, ainsi que la majorité des hôtes de fichiers.
Regardez aussi Paypal, 3d secure, la plupart des systèmes bancaires, EBAY, Amazon, Alibaba, Facebook, la liste est interminable.
TOUS utilisent des iframes. Visitez les 100 meilleurs sites Web, consultez la source - pariez que vous trouvez des iframes sur presque tous.