Question:
Risques spécifiques liés à l'intégration d'une iframe HTTPS dans une page HTTP
Dan Kohn
2013-07-02 23:34:05 UTC
view on stackexchange narkive permalink

J'ai besoin d'aide pour répertorier les risques spécifiques liés à l'intégration d'une iframe HTTPS qui permet le paiement par carte de crédit à l'intérieur d'une page HTTP. Y a-t-il des problèmes de sécurité lors de l'intégration d'une iframe HTTPS sur une page HTTP? pose quelques problèmes de haut niveau, mais je souhaite être aussi précis que possible sur les vecteurs d'attaque potentiels. Cliquez sur Acheter maintenant pour un bon exemple d'iframe sécurisé à l'intérieur d'une page non sécurisée, utilisé aujourd'hui pour les transactions par carte de crédit. Voici ce que j'ai jusqu'à présent:

  • La conversion sera probablement inférieure, car les utilisateurs avertis sauront qu'ils ne doivent pas entrer leur numéro de carte de crédit sans voir un verrou vert dans l'URL du navigateur Chrome. (Les utilisateurs moins avertis peuvent ne pas savoir qu'ils ne devraient pas faire confiance à un verrou apparaissant dans le cadre du navigateur, comme dans l'exemple ci-dessus.)
  • Même si les utilisateurs sont à l'aise avec cette approche, c'est généralement une mauvaise idée de encouragez les utilisateurs à saisir leur numéro de carte de crédit lorsqu'ils ne voient pas de confirmation de verrouillage SSL dans la barre d'URL. Il enseigne aux utilisateurs de mauvaises habitudes de sécurité. Cet article fait valoir que SSL est une question de sécurité plus que simplement le cryptage et l'authentification.
  • Un homme actif au milieu pourrait injecter un script non autorisé dans la page parente qui pourrait fouiller les touches . Je crois que c'est ce que le gouvernement tunisien a fait pour voler les informations d'identification des dissidents sur Facebook. (Je crois que le script non autorisé serait empêché d'accéder au nom d'utilisateur et au mot de passe de l'iframe sécurisé, mais pourrait toujours accéder aux frappes). Bien sûr, une autorité gouvernementale plus déterminée pourrait également corrompre le DNS et forger un certificat SSL, comme l’a fait apparemment le gouvernement iranien, auquel cas une page parent sécurisée n’aiderait pas.

J'ai aussi cette liste de problèmes irréalistes:

  • Un autre objet Javascript sur la page parent non sécurisée pourrait fouiller le contenu de l'iframe sécurisé. Je pense que cela n'est plus possible tant que seuls les navigateurs IE8 et supérieurs sont pris en charge.
  • Un objet Javascript non autorisé sur la page parente peut effectuer une journalisation des frappes pour capturer le numéro de carte de crédit d'un utilisateur. Cela peut être possible, mais le risque n'est pas affecté par le fait que la page parent soit diffusée via SSL ou non. Un script non autorisé pourrait fouiller les touches de toute façon.
  • L'utilisateur ne peut pas voir l'URL à partir de laquelle l'iframe sécurisée est diffusée. Avec une page parent sécurisée ou non sécurisée, vous devez être un utilisateur techniquement sophistiqué pour afficher l'URL source de l'iframe.

Pourriez-vous me dire ce que d'autres vulnérabilités réalistes et irréalistes qui me manquent? Je n'ai aucun doute que la meilleure option est toujours d'intégrer un iframe sécurisé dans une page parent sécurisée. Ce que j'essaie de décider, ce sont les risques et les avantages relatifs de l'activation d'une iframe sécurisée à l'intérieur d'une page non sécurisée par rapport à la mauvaise expérience utilisateur consistant à expulser les utilisateurs du site non sécurisé où ils voient le produit afin d'effectuer une commande sécurisée ailleurs.

Les trois premières raisons semblent plus que suffisantes. Je recommanderais activement aux gens de ne pas acheter sur ce site. Les utilisateurs ont été formés à plusieurs reprises pour rechercher `https` dans la barre d'URL d'un domaine connu. Bien que je puisse essayer de vérifier qu'il n'y a pas de keylogging non autorisé JS et HTTPS est réellement utilisé (à chaque fois - et le contrôle sans keylogging n'est pas anodin avec JS minifié), je ne m'attendrais pas à ce que la plupart des utilisateurs puissent le faire. Aussi, comment puis-je savoir que la connexion HTTPS pour `ninjastandingdesk.com` est censée être vers` newrelic.com` et que ce n'est pas une attaque MitM?
Ne mettez jamais, jamais une page protégée SSL dans un iframe d'une page non SSL. Cela pose des problèmes, vous giflerez la confiance des utilisateurs au visage, et enfin et surtout, cela pourrait avoir une mauvaise influence sur votre karma de sécurité. Amusement à part: ne le faites pas.
Je sais que c'est une vieille question, mais FWIW le lien "Acheter maintenant" ne montre plus la situation iframe http + https décrite.
Deux réponses:
Tom Leek
2013-07-03 00:20:05 UTC
view on stackexchange narkive permalink

Un attaquant qui peut intégrer un script non autorisé dans la page parente peut également simplement modifier l'URL de l'iframe, en la redirigeant vers un emplacement arbitraire, auquel cas toutes sortes de configurations de phishing et de man-in-the-middle sont faciles . Pas besoin de jouer des tours DNS à ce niveau. C'est le principal problème avec une telle iframe HTTPS: vous ne pouvez pas facilement savoir si vous avez la chose authentique (vous devez activer le mode de débogage du navigateur pour être vraiment sûr - un coup d'œil rapide à la source de la page n'est finalement pas suffisant car les scripts chargés de la page peut le manipuler à volonté au niveau du DOM, donc ce que vous semblez voir dans le code source n'est pas nécessairement ce que vous obtenez).

Cela se résume vraiment à l'absence de barre d'URL pour le iframe. Pour un site HTTPS, la barre d'URL vous indique que SSL approprié est en place, avec un certificat de serveur valide, et il vous indique le nom du serveur auquel vous parlez réellement. Supprimez la barre et toutes sortes de trucs désagréables deviennent possibles.

Du bon côté , une iframe HTTPS, comme une URL cible HTTPS pour un formulaire de connexion dans une page HTTP , est excellent contre les attaquants passifs uniquement (le genre d'attaquants qui écoute tous les octets échangés mais n'injecte jamais rien de lui-même). Il se trouve que croire que la plupart des attaquants sont uniquement passifs est devenu de nos jours singulièrement naïf.

En ce qui concerne l'expérience utilisateur, la recommandation habituelle est simplement de rendre l'ensemble du site HTTPS. C'est beaucoup moins cher, d'un point de vue informatique, qu'on ne le croit habituellement. De manière générale, les humains ne sont pas doués pour prédire les problèmes de performances. La performance est une question de mesure, pas de devinettes. Je vous suggère de l'essayer.

De plus, en tant qu'utilisateur (mais pas nécessairement un utilisateur typique ), j'aime un peu la transition visible de HTTP à HTTPS. Le paiement est une question d’argent et, surtout, de mon argent. C'est donc important .

Pour être clair, mon site (qui est la source de l'iFrame intégré) est uniquement SSL. Le problème est que nous fournissons du Javascript tiers (espérons-le) à des milliers d'autres sites, et beaucoup d'entre eux peuvent avoir du mal à activer SSL. Indépendamment de l'installation d'un certificat, ces sites codent souvent des images HTTP dans leur CSS et font d'autres erreurs qui provoquent des avertissements de contenu mixte.
http://wordpress.org/plugins/wordpress-https/ est une excellente solution pour ajouter facilement SSL aux blogs Wordpress (bien que vous deviez toujours corriger les URL non indépendantes du protocole référencées dans le CSS). Cependant, il n'existe actuellement aucun moyen de sécuriser Tumblr et d'autres sites de blog tiers.
Voir aussi: http://security.stackexchange.com/questions/31748/credit-card-forms-on-http-pages-a-mitm-risk qui couvre des questions étroitement liées.
Tom, c'était une excellente réponse. Désolé, je ne peux pas les marquer tous les deux comme corrects.
bobince
2013-07-03 13:48:58 UTC
view on stackexchange narkive permalink

Cliquez sur Acheter maintenant pour un bon exemple d'iframe sécurisé à l'intérieur d'une page non sécurisée, utilisé aujourd'hui pour les transactions par carte de crédit.

Mis à part toutes les raisons techniques mentionnées c'est une chose désastreusement mauvaise, c'est explicitement contre les exigences PCI-DSS. Reportez-vous à l'exigence 4.1 "Naviguer dans DSS 2.0": 

  Lorsque vous utilisez des sites Web sécurisés SSL, assurez-vous que "https" fait partie de l'URL

L'interface liée est dans violation des conditions PCI auxquelles les commerçants souscrivent dans le cadre de leur accord avec leur banque. ShopLocket semble fournir / encourager une approche manifestement non conforme à la norme PCI ainsi qu'une approche profondément discutable du traitement des cartes.

http://example.com/https/, heh. (Dans ce sens, je me demande si http://evilsite.com/secure-checkout?secure=yes pourrait jamais tromper quelqu'un)


ⓘ
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 3.0 sous laquelle il est distribué.
Loading...