Pourquoi les iframes sont-ils considérés comme dangereux et constituent-ils un risque pour la sécurité?
Pourquoi les iframes sont-ils considérés comme dangereux et constituent-ils un risque pour la sécurité? Quelqu'un peut-il décrire un exemple de cas où il peut être utilisé à des fins malveillantes?
Dès que vous affichez du contenu provenant d'un autre domaine, vous faites essentiellement confiance à ce domaine pour ne pas servir de logiciels malveillants.
Il n'y a rien de mal avec les iframes en soi. Si vous contrôlez le contenu de l'iframe, il est parfaitement sûr.
L'élément IFRAME peut constituer un risque pour la sécurité si votre site est intégré à un IFRAME sur un site hostile . Google "clickjacking" pour plus de détails. Notez que peu importe si vous utilisez <iframe> ou pas. La seule protection réelle contre cette attaque consiste à ajouter un en-tête HTTP X-Frame-Options: DENY et espérons que le navigateur connaît son travail.
De plus, l'élément IFRAME peut constituer un risque pour la sécurité si une page de votre site contient une vulnérabilité XSS pouvant être exploitée . Dans ce cas, l’attaquant peut étendre l’attaque XSS à n’importe quelle page du même domaine pouvant être persuadée de se charger dans un <iframe> sur la page présentant une vulnérabilité XSS. En effet, le contenu de la même origine (même domaine) est autorisé à accéder au contenu DOM du contenu parent (pratiquement exécuter 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 correctement coder toutes les données soumises par les utilisateurs (c'est-à-dire ne jamais avoir une vulnérabilité XSS sur votre site - plus facile à dire qu'à faire).
C'est le côté technique de la question. De plus, il y a le problème de l'interface utilisateur. Si vous apprenez à vos utilisateurs à faire confiance à la barre d'adresse supposée ne pas changer lorsqu'ils cliquent sur des liens (par exemple, votre site utilise une grande iframe avec tout le contenu actuel), les utilisateurs ne remarqueront rien à l'avenir non plus en cas de vulnérabilité de sécurité réelle. Par exemple, une vulnérabilité XSS sur votre site pourrait permettre à l’attaquant de charger du contenu à partir de sources hostiles au sein de votre iframe. Personne ne pourrait faire la différence, car la barre d'adresse semble toujours identique au comportement précédent (ne change jamais) et le contenu "semble" valide même s'il provient d'un domaine hostile demandant des informations d'identification d'utilisateur.
Si quelqu'un prétend que l'utilisation d'un <iframe> L’élément de votre site est dangereux et pose un risque pour la sécurité, il ne comprend pas ce que <iframe> l’élément fait, ou il parle de possibilité de <iframe> vulnérabilités liées dans les navigateurs. Sécurité de <iframe src="..."> tag est égal à <img src="..." ou <a href="..."> tant qu'il n'y a pas de vulnérabilités dans le navigateur. Et s’il existe une vulnérabilité appropriée, il pourrait être possible de la déclencher même sans utiliser <iframe>, <img> ou <a> _ élément, il n’est donc pas utile d’envisager ce problème.
Cependant, soyez averti que le contenu de <iframe> peut lancer la navigation de niveau supérieur par défaut . C'est-à-dire contenu dans le <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 sandbox attribut 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 de Youtube ne peut pas être mis en sandbox, car Flash Player est toujours requis pour afficher tout le contenu de Youtube. Aucun navigateur ne prend en charge l’utilisation de plug-ins et l’interdiction de la navigation de haut niveau en même temps.
Notez que X-Frame-Options: DENY protège également des attaques contre les canaux secondaires qui rendent le contenu pouvant lire le contenu de différentes origines (également appelé " Pixel perfect Timing Attacks ").
Je suppose qu'iFrame est inter-domaines, car le risque serait probablement plus faible si vous le contrôliez vous-même.
- Clickjacking est un problème si votre site est inclus en tant que iframe
- Un iFrame compromis pourrait afficher du contenu malveillant (imaginez l’iFrame affichant une zone de connexion au lieu d’une annonce).
- Une iframe incluse peut effectuer certains appels JS tels que alert et Prompt, ce qui pourrait gêner votre utilisateur.
- Un iframe inclus peut rediriger via location.href (oui, imaginez un cadre 3p redirigeant le client de bankofamerica.com à bankofamerica.fake.com)
- Les logiciels malveillants contenus dans le cadre 3p (Java/flash/activeX) pourraient infecter votre utilisateur
"Dangereux" et "risque pour la 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 clickjacking .
ifram est également une vulnérabilité contre Cross Frame Scripting " https://www.owasp.org/index.php/Cross_Frame_Scripting "