Est-il sûr de soumettre un formulaire HTTP à HTTPS?
Est-il acceptable de soumettre un formulaire http via https? Il semble que cela devrait être sécurisé, mais cela permet à un homme au milieu d'attaquer ( voici une bonne discussion ). Il existe des sites comme mint.com qui vous permettent de vous connecter à partir d'une page http mais qui publie un article https. Sur mon site, la demande est d'avoir une page de destination http mais de pouvoir se connecter en toute sécurité. Cela ne vaut-il pas le risque de sécurité possible et dois-je simplement obliger tous les utilisateurs à se connecter à une page sécurisée (ou à sécuriser la page de destination)?
Y a-t-il une raison pas à utiliser HTTPS pour toute la transaction? Si vous n'en trouvez pas un très bon, utilisez-le!
C'est sans doute plus simple que de changer de protocole.
Le risque MITM est réel.
Suite à votre lien, l'utilisateur "Helios" fait un excellent point que l'utilisation de 100% HTTPS est beaucoup moins déroutant pour l'utilisateur.
La publication d'un formulaire d'une page http vers une page https crypte les données du formulaire lorsqu'elles sont transmises dans les termes les plus simples. S'il y a une attaque d'homme au milieu, le navigateur vous avertira.
Cependant, si le formulaire http d'origine a été soumis à man-in-the-middle et que l'adresse post-back https a été modifiée par l'attaquant, vous ne recevrez aucun avertissement. Les données seront toujours cryptées, mais l'attaquant de l'homme du milieu pourrait décrypter (puisqu'il vous a envoyé la clé en premier lieu) et lire les données.
De plus, si le formulaire renvoie des éléments par d'autres moyens (connexions par script), il peut y avoir une possibilité que des données non cryptées soient envoyées par câble avant la publication du formulaire (bien qu'un bon site Web ne le fasse jamais avec aucun type de données sensibles) .
Ce genre de chose apparaît partout sur le net, en particulier dans les sites pour lesquels la connexion est facultative. Cependant, il est intrinsèquement dangereux, pour des raisons assez subtiles, et donne à l'utilisateur un faux sentiment de sécurité. Je pense qu'il y a eu un article à ce sujet récemment sur codinghorror.com .
Le danger est que pendant que vous envoyez votre page avec une cible de publication " https: // xxx ", la page dans laquelle cette référence apparaît n'est pas sécurisée, elle peut donc être modifiée en transit par un attaquant pour pointer vers n'importe quelle URL que l'attaquant souhaite. Donc, si je visite votre site, je dois consulter la source pour vérifier que mes informations d'identification sont publiées sur une adresse sécurisée, et que la vérification n'a de pertinence que pour cela soumettre en particulier. Si je reviens demain, je dois à nouveau consulter la source, car cette livraison particulière de la page peut avoir été attaquée et la cible de publication subvertie - si je ne vérifie pas à chaque fois, au moment où je sais que la cible de publication a été subvertie, c'est trop tard - j'ai déjà envoyé mes informations d'identification à l'URL de l'attaquant.
Vous devez seulement fournir un lien vers la page de connexion; et la page de connexion et tout ce qui suit devrait être HTTPS tant que vous êtes connecté. Et, vraiment, il n'y a aucune raison de ne pas le faire; la charge de SSL est sur la négociation initiale; les connexions suivantes utiliseront la mise en cache de session SSL et la cryptographie symétrique utilisée pour les données de liaison est en fait un surdébit extrêmement faible.
Blog IE explique: Erreur critique # 1: Pages de connexion non-HTTPS (même si vous soumettez à une page HTTPS)
- Comment l'utilisateur sait-il que le formulaire est envoyé via HTTPS? La plupart des navigateurs ne disposent pas d'un tel indice d'interface utilisateur.
- Comment l'utilisateur pouvait-il savoir qu'il allait sur la bonne page HTTPS? Si le formulaire de connexion a été livré via HTTP, il n'y a aucune garantie qu'il n'a pas été changé entre le serveur et le client.
Jay et Kiwi ont raison sur l'attaque du MITM. Cependant, il est important de noter que l'attaquant n'a pas à casser le formulaire et à donner un message d'erreur; l'attaquant peut à la place insérer JavaScript pour envoyer les données du formulaire deux fois, une fois pour lui et une fois pour vous.
Mais, honnêtement, vous devez vous demander, quelle est la probabilité qu'un attaquant intercepte votre page de connexion et la modifie en vol? Comment cela se compare-t-il au risque de (a) faire un détroit d'attaque MITM sur la session SSL et espérer que l'utilisateur appuie sur "OK" pour continuer; (b) faire le MITM sur votre redirection initiale vers SSL (par exemple, de http://example.com à https://example.com ) et rediriger vers - https://doma1n.com à la place, qui est sous le contrôle de l'attaquant; (c) Vous avez un défaut d'injection XSS, XSRF ou SQL quelque part sur votre site.
Oui, je suggère d'exécuter le formulaire de connexion sous SSL, il n'y a aucune raison de ne pas le faire. Mais je ne m'inquiéterais pas beaucoup si ce n'était pas le cas, il y a probablement des fruits suspendus bien inférieurs.
Mise à jour
La réponse ci-dessus date de 2008. Depuis lors, de nombreuses menaces supplémentaires sont apparues. Par exemple, accéder à des sites à partir de réseaux aléatoires non fiables tels que des points d'accès Wi-Fi (où n'importe qui à proximité peut être en mesure de réussir cette attaque). Maintenant, je dirais que oui, vous devez certainement crypter votre page de connexion et faire avancer votre site tout entier. De plus, il existe maintenant des solutions au problème de redirection initial (HTTP Strict Transport Security). Open Web Application Security Project met à disposition plusieurs guides de bonnes pratiques.
Pour moi (en tant qu'utilisateur final), la valeur d'une session HTTPS n'est pas seulement que les données sont cryptées, mais que j'ai la vérification que la page dans laquelle je tape mes super secrets vient de l'endroit où je le veux à.
Avoir le formulaire dans une session non HTTPS annule cette assurance.
(Je sais - c'est juste une autre façon de dire que le formulaire est sujet à une attaque MITM).
Ce message est la clé. Oui, si les données de l'utilisateur vous sont envoyées, elles seront arrivées quelque part en toute sécurité. Mais il n'y a aucune raison de croire que quelque part sera votre site. L'attaquant n'écoutera pas seulement les données se déplaçant dans chaque direction à ce stade. Il sera l'autre bout de la session de l'utilisateur. Votre site va juste penser que l'utilisateur n'a jamais pris la peine de soumettre le formulaire.
Tout le monde suggérant que vous fournissez uniquement un lien vers la page de connexion semble oublier que le lien pourrait facilement être modifié à l'aide d'une attaque MITM.
Non, il n'est pas sûr de passer de HTTP à HTTPS. Les points d'origine et résultants de la demande doivent être HTTPS pour que le canal sécurisé soit établi et utilisé.