Question:
Y a-t-il des problèmes de sécurité lors de l'intégration d'une iframe HTTPS sur une page HTTP?
Yahel
2010-11-30 23:13:04 UTC
view on stackexchange narkive permalink

J'ai vu des sites Web placer des iframes HTTPS sur des pages HTTP.

Y a-t-il des problèmes de sécurité à ce sujet? Est-il sûr de transmettre des informations privées telles que les détails de la carte de crédit dans un tel schéma (où les informations ne sont placées que sur le formulaire iframe HTTPS et non sur la page parent HTTP)?

Voir également https://security.stackexchange.com/q/38317/16960
Six réponses:
#1
+47
user502
2010-11-30 23:35:09 UTC
view on stackexchange narkive permalink

Si seule l'iframe est https, l'utilisateur ne peut pas voir de manière triviale l'URL vers laquelle il pointe. Par conséquent, la page http source pourrait être modifiée pour pointer l'iframe n'importe où. C'est à peu près une vulnérabilité de game-over qui élimine les avantages de https.

+1 pour avoir souligné l'importance de * l'authentification du serveur *, qui est souvent oubliée comme un avantage de SSL.
Je reconnais que c'est une vieille question, mais j'espérais que quelqu'un pourrait expliquer comment le fait d'avoir HTTPS dans la page d'origine résout le problème d'un script non autorisé modifiant l'emplacement de l'iframe?Si la page d'origine est HTTPS, il se peut qu'un script non autorisé modifie la destination iframe, non?
@MattJames, si la page d'origine est également HTTPS, elle ne peut pas être modifiée en transit à moins que MitM ne dispose d'un certificat valide pour le domaine (ce qui ne devrait pas se produire à moins que les autorités de certification ne font pas leur travail).Ils peuvent cependant toujours intercepter la charge HTTP -> HTTPS d'origine et la rediriger vers un domaine sous leur contrôle.Les utilisateurs pourraient le détecter en regardant l'URL et le certificat, qui ne sont affichés que pour le cadre supérieur.Cela dit, la plupart des utilisateurs ne le remarqueraient probablement pas, ce qui est l'une des raisons pour lesquelles les comptes sont parfois compromis.
L'hypothèse bien sûr est que l'attaquant est assis sur le réseau.S'ils peuvent modifier la page source sur le serveur pour inclure du code non autorisé, alors tous les paris sont désactivés.De même, s'ils peuvent obtenir un script qui peut modifier le contenu de la page installé dans le navigateur de l'utilisateur, ils sont également vulnérables.(Les personnes utilisant Greasemonkey / Tampermonkey / etc doivent donc se méfier, bien que beaucoup ne le soient pas encore.)
#2
+18
goodguys_activate
2010-12-01 01:01:06 UTC
view on stackexchange narkive permalink

iFrames exposera le site HTTPS interne à de nombreuses attaques javascript et cookies dans les navigateurs plus anciens, et peut causer des problèmes dans les navigateurs plus récents.

Pour résoudre ce problème, recherchez "Frame Busting" pour détecter si des iFrames sont utilisés. Considérez cette solution sur StackOverflow:

https://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed

Dans ce code, vous pouvez détecter si des iFrames sont utilisés et proposer un contenu alternatif pour diriger l'utilisateur vers le site approprié.

#3
+15
Paul
2010-12-01 01:18:20 UTC
view on stackexchange narkive permalink

Un iframe HTTPS dans une page servie via HTTP ne permettra pas à l'utilisateur d'être sûr qu'il utilise réellement la connexion HTTPS qu'il attend à être; par conséquent, cela permet potentiellement à l'iframe d'être détourné lors d'une simple attaque telle qu'une injection d'iframe. Cela permettrait, entre autres, la récolte de mots de passe. Une telle attaque pourrait commencer par un cheval de Troie, un virus ou simplement visiter un site Web malveillant.

#4
+7
symcbean
2010-12-01 22:06:35 UTC
view on stackexchange narkive permalink

Oui, alors que les navigateurs les plus récents mettront correctement en sandbox les parties SSL, vous sapez toutes les fonctionnalités ajoutées au chrome du navigateur pour fournir des commentaires des utilisateurs sur le contenu. Pour ma part, je ne fournirais aucune information sensible sans vérifier l'URL affichée dans mon navigateur.

#5
+2
Dominique
2011-06-04 02:38:00 UTC
view on stackexchange narkive permalink

En plus des possibles scénarios de piratage déjà donnés, vous pouvez rencontrer des problèmes sur IE6 / 7 si vous pointez vers une page HTTP ou HTTPS nécessitant une connexion. Fondamentalement, les cookies de la page de l'iframe s'attendent à ce que vous utilisiez le même protocole (HTTP ou HTTPS) et donc si la page sur laquelle vous mettez l'iframe utilise HTTP au lieu de HTTPS, cela empêcherait l'utilisateur de pouvoir connectez-vous.

cette réponse semble confuse. Je ne sais pas ce que vous essayez de dire ni à quel problème vous faites allusion.
Les cookies ne sont pas partagés entre http et https
#6
  0
gnasher729
2019-10-19 18:16:23 UTC
view on stackexchange narkive permalink

Toute requête http signifie deux choses: premièrement, les pirates peuvent fouiner et lire à la fois la requête et la réponse. Deuxièmement, les pirates pourraient être en mesure de renvoyer un site Web différent de celui d'origine.

Donc, si j'accède à votre site Web via http et que je reçois un lien https en retour, les pirates peuvent en apprendre davantage sur ce lien https, mais dans l'ensemble, ce n'est pas moins sécurisé qu'un lien http.

Cependant, il n'y a aucune garantie que j'ai reçu votre site Web et non celui fourni par un pirate informatique. Ainsi, le cadre https peut même ne pas être présent sur le bon site, uniquement sur celui piraté. Et il n'y a aucune garantie du tout où il pointe, donc aucune sécurité du tout.

Une fois que vous avez commencé avec http, en ce qui concerne la sécurité, la partie est terminée.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...