Est-il acceptable de présenter à partir d'un formulaire http par https? Il semble que ce devrait être sécurisé, mais il permet à un man in the middle attack (ici, c'est un bon sujet de discussion). Il y a des sites comme mint.com qui vous permettent de vous connecter à partir d'une page http, mais ne post https. Dans mon site, la demande est d'avoir un http de la page de destination, mais être capable de se connecter de manière sécurisée. N'est-il pas la peine de le possible risque pour la sécurité et-ce que je dois faire tous les utilisateurs vers une page sécurisée de connexion (ou de faire de la page d'atterrissage sécurisé)?
Réponses
Trop de publicités?
Jason Coco
Points
52303
L'affichage d'un formulaire à partir d'une page http d'une page https ne chiffrer les données dans le formulaire lorsqu'il est transmis dans les termes les plus simples. Si il y a un man-in-the-middle attack, le navigateur vous avertit.
Toutefois, si l'original http formulaire a été soumis à un man-in-the-middle et le https de l'après-back de l'adresse a été modifiée par l'attaquant, alors vous n'aurez pas de message d'avertissement. Les données vont encore être chiffré, mais l'homme-dans-le-milieu attaquant serait en mesure de les déchiffrer (depuis qu'il vous a envoyé la clé en premier lieu) et de lire les données.
Aussi, si le formulaire est à envoyer des choses par d'autres moyens (par script connexions), il peut y avoir un risque de non chiffrées données envoyées sur le fil avant que le formulaire est posté (même si tout bon site web serait de ne jamais faire cela avec n'importe quel type de données sensibles).
Est-il une raison de ne pas utiliser HTTPS pour l'ensemble de la transaction? Si vous ne pouvez pas trouver un très bon produit, de l'utiliser!
C'est sans doute plus simple que le changement de protocoles.
Le MITM risque est réel.
En suivant votre lien, l'utilisateur "Helios" est un excellent point que l'utilisation de 100% HTTPS est beaucoup moins à confusion pour l'utilisateur.
Lawrence Dol
Points
27976
Ce genre de chose est surgissent un peu partout sur le net, en particulier dans les sites pour lesquels la connexion est facultatif. Cependant, il est intrinsèquement dangereux, pour assez subtiles raisons, et donne à l'utilisateur un faux sentiment de sécurité. Je pense qu'il y avait un article à ce sujet récemment sur codinghorror.com.
Le danger est que si vous avez envoyé votre page avec une cible post de "https://xxx", à la page dans laquelle le renvoi n'est pas sécurisé, de sorte qu'il peut être modifié en cours de route par un attaquant pour pointer vers n'importe quelle URL de l'attaquant souhaite. Donc, si je visite votre site, je dois afficher la source pour vérifier mes informations d'identification qui sont envoyés à une adresse sécurisée, et que la vérification de la pertinence uniquement pour le soumettre. Si je reviens demain, je dois afficher la source, étant donné que la prestation de la page peut avoir été attaqué et la cible post subverti - si je n'ai pas vérifier à chaque fois, par le temps, je sais que le poste cible a été renversé, il est trop tard - j'ai déjà envoyé mes informations d'identification à l'agresseur de l'URL.
Vous devez seulement fournir un lien vers la page de connexion; et la page de connexion et tout, par la suite, devrait être en HTTPS pour aussi longtemps que vous êtes connecté. Et, vraiment, il n'y a aucune raison de ne pas, la charge de SSL est sur la négociation initiale; les connexions de l'utilisation de SSL session de la mise en cache et le symétrique de chiffrement utilisé pour la liaison de données est en fait extrêmement faible surcharge.
porneL
Points
42805
Blog IE explique: Erreur #1: Non-HTTPS pages de Connexion (même si la soumission à une page HTTPS)
- Comment l'utilisateur de savoir que le formulaire est soumis par l'intermédiaire du HTTPS? La plupart des navigateurs n'ont pas une telle INTERFACE utilisateur de repère.
- Comment l'utilisateur de savoir qu'il était à la bonne page HTTPS? Si le formulaire de connexion a été livré par HTTP, il n'y a aucune garantie qu'il n'a pas été modifié entre le serveur et le client.
derobert
Points
26258
Jay et Kiwi sont juste à propos de l'attaque de type MITM. Toutefois, il est important de noter que l'attaquant n'a pas à briser le formulaire et donner un message d'erreur; l'attaquant peut, au lieu d'insérer du JavaScript pour envoyer les données du formulaire, une fois pour lui et une fois à vous.
Mais, honnêtement, vous devez vous demander, quelles sont les chances pour un attaquant de détourner votre page de connexion et de le modifier en cours de vol? Comment est-il comparer le risque de (a) faire une attaque de type MITM détroit sur la session SSL, et en espérant que l'utilisateur appuie sur "OK" pour continuer; (b) faire du MITM sur votre première rediriger vers SSL (par exemple, à partir de http://domain.com pour https://domain.com) et de la rediriger vers https://doma1n.com au lieu de cela, qui est sous le contrôle de l'attaquant; (c) avoir une XSS, XSRF, ou par injection SQL faille quelque part sur votre site.
Oui, je vous suggère de courir le formulaire de connexion sous SSL, il n'y a pas de raison de ne pas. Mais je ne m'inquiéterais pas beaucoup si ce n'était pas le cas, il y a probablement beaucoup plus faible fruits mûrs.
