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.