Risques spécifiques liés à l'intégration d'une iframe HTTPS dans une page HTTP
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é avec l'incorporation d'un iframe HTTPS sur une page HTTP? fournit quelques préoccupations de haut niveau, mais je cherche à être aussi précis que possible sur les vecteurs d'attaque potentiels. Cliquez sur Acheter maintenant pour un bon exemple d'un 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 plus faible, car les utilisateurs avertis sauront de ne pas entrer leur numéro de carte de crédit sans voir un verrou vert dans l'URL dans le chrome du navigateur. (Les utilisateurs moins avertis peuvent ne pas savoir qu'ils ne devraient pas faire confiance à un verrou apparaissant à l'intérieur du 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 d'encourager les utilisateurs à entrer 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 plus une question de sécurité que de chiffrement et d'authentification.
- Un homme actif au milieu pourrait injecter un script escroc dans la page parent qui pourrait fouiner. Je crois que c'est ce que le gouvernement tunisien a fait pour voler les informations d'identification Facebook des dissidents. (Je crois que le script escroc serait empêché d'accéder au nom d'utilisateur et au mot de passe à partir de l'iframe sécurisé, mais pourrait toujours accéder aux frappes). Bien sûr, une autorité gouvernementale plus déterminée pourrait inverser le DNS et falsifier un certificat SSL, comme le gouvernement iranien l'a apparemment fait, auquel cas une page parent sécurisée n'aiderait pas.
J'ai également cette liste de préoccupations irréalistes:
- Un autre objet Javascript sur la page parent non sécurisée pourrait espionner 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 escroc sur la page parent pourrait effectuer une journalisation des touches 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 servie via SSL ou non. Un script escroc pourrait espionner les touches dans les deux sens.
- L'utilisateur ne peut pas voir l'URL à partir de laquelle l'iframe sécurisé est servi. Avec une page parent sécurisée ou non sécurisée, vous devez être un utilisateur techniquement sophistiqué pour afficher l'URL source iframe.
Pourriez-vous me dire quelles sont les autres vulnérabilités réalistes et irréalistes qui me manquent? Je ne doute pas que la meilleure option est toujours d'incorporer un iframe sécurisé dans une page parent sécurisée. Ce que j'essaie de décider, ce sont les risques et avantages relatifs de l'activation d'une iframe sécurisée dans une page non sécurisée par rapport à la mauvaise expérience utilisateur de sauter des utilisateurs du site non sécurisé où ils voient le produit afin de terminer un paiement sécurisé ailleurs.
Cliquez sur Acheter maintenant pour un bon exemple d'un 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 mauvaise chose désastreuse, c'est explicitement contraire aux exigences PCI-DSS. Voir "Naviguer DSS 2.0" exigence 4.1:
When using SSL secured websites, ensure “https” is part of the URL
L'interface liée ne respecte pas les conditions PCI auxquelles les commerçants s'inscrivent dans le cadre de leur accord avec leur banque. ShopLocket semble fournir/encourager une approche manifestement non conforme au PCI ainsi qu'une approche profondément discutable du traitement des cartes.
Un attaquant qui peut intégrer un script escroc dans la page parent peut également simplement changer l'URL de l'iframe, en le 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 un tel iframe HTTPS: vous ne pouvez pas facilement savoir si vous avez obtenu la chose authentique (vous devez activer le mode de débogage du navigateur pour être vraiment sûr - un aperçu rapide de la source de la page n'est finalement pas suffisant car les scripts chargés depuis 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 l'iframe. Pour un site HTTPS, la barre d'URL vous indique que le bon SSL est en place, avec un certificat de serveur valide, et il vous indique le nom du serveur vous parlez en fait. Retirez la barre et toutes sortes de trucs désagréables deviennent possibles.
Du bon côté, un iframe HTTPS, comme une URL cible HTTPS pour un formulaire de connexion dans une page HTTP, est excellent contre les attaquants passifs uniquement (le type d'attaquants qui écoute tous les octets échangés mais n'injecte jamais rien par lui-même). Il se trouve que croire que la plupart des attaquants sont uniquement passifs est devenu singulièrement naïf de nos jours.
Quant à l'expérience utilisateur, la recommandation habituelle est tout simplement de rendre l'ensemble du site HTTPS. C'est beaucoup moins cher, d'un point de vue informatique, qu'on ne le pense habituellement. D'une manière générale, les humains ne sont pas bons pour prédire les problèmes de performances. La performance est une question de mesure, pas de supposition. Je vous suggère de l'essayer.
En outre, en tant qu'utilisateur (mais pas nécessairement un utilisateur typique ), J'aime un peu la transition visible de HTTP à HTTPS. Le paiement concerne l'argent et, surtout, mon argent. Ainsi, il est important .