Question:
Est-ce que la publication de HTTP vers HTTPS est une mauvaise pratique?
Troy Hunt
2011-01-18 06:36:51 UTC
view on stackexchange narkive permalink

En partant du principe que SSL sert à la fois à crypter les données et pour fournir une assurance quant à l'identité et à la légitimité du site Web, si la pratique consistant à fournir un formulaire de connexion sur une page demandée via HTTP, même si elle publie sur HTTPS?

La question concerne un message que j'ai publié hier à propos de Qui est qui des mauvaises pratiques de mot de passe et certains des les commentaires suggérant que ne pas voir visiblement le certificat représenté dans le navigateur avant de s'authentifier était bien si effectivement le formulaire affiché en toute sécurité.

À mon avis, cela vend le SSL à découvert car vous perdez non seulement la capacité de valider la légitimité du site avant de transmettre vos informations d'identification, mais vous n'avez pas non plus la certitude qu'il est publication via HTTPS. Je suis conscient que Twitter et Facebook adoptent cette approche, mais devraient-ils? Suis-je en train d'oublier quelque chose ici ou est-ce une pratique qui devrait être découragée?

Mise à jour: J'ai fini par détailler le résultat de cette question et la discussion qui a suivi dans l'article de blog SSL ne concerne pas le cryptage

Quatre réponses:
#1
+58
Tate Hansen
2011-01-18 06:43:11 UTC
view on stackexchange narkive permalink

OWASP déclare:

(copié textuellement de http://www.owasp.org/index.php/SSL_Best_Practices)

Pages de connexion sécurisées
Il existe plusieurs considérations majeures pour concevoir en toute sécurité une page de connexion. Le texte suivant abordera les considérations relatives à SSL.

Les connexions doivent être publiées sur une page SSL C'est assez évident. Le nom d'utilisateur et le mot de passe doivent être publiés via une connexion SSL. Si vous regardez l'élément d'action du formulaire, il doit être https.

La page de destination de connexion doit utiliser SSL La page réelle où l'utilisateur remplit le formulaire doit être une page HTTPS . Si ce n'est pas le cas, un attaquant pourrait modifier la page lorsqu'elle est envoyée à l'utilisateur et changer l'emplacement de soumission du formulaire ou insérer du JavaScript qui vole le nom d'utilisateur / mot de passe au fur et à mesure de la saisie.

Il doit y avoir pas de message d'erreur ou d'avertissement SSL La présence d'un message d'avertissement SSL est un échec. Certains de ces messages d'erreur sont des problèmes de sécurité légitimes; d'autres désensibilisent les utilisateurs à de réels problèmes de sécurité puisqu'ils cliquent aveuglément sur Accepter. La présence de tout message d'erreur SSL est inacceptable - même une incompatibilité de nom de domaine pour www.

Les connexions HTTP doivent être supprimées Si un utilisateur tente de se connecter à la version HTTP de la connexion page la connexion doit être refusée. Une stratégie consiste à rediriger automatiquement les connexions HTTP vers les connexions HTTPS. Bien que cela amène l'utilisateur à la page sécurisée, il existe un risque persistant. Un attaquant effectuant une attaque de type "homme au milieu" pourrait intercepter la réponse de redirection HTTP et envoyer l'utilisateur vers une autre page.

Pour répéter: La page de destination de connexion doit utiliser SSL

Utilisez HSTS pour forcer HTTPS
@danday74 Il est intéressant de noter que l'en-tête HSTS est ignoré s'il est envoyé via HTTP (car un attaquant pourrait injecter / supprimer l'en-tête à volonté), vous devez donc les envoyer sur une page HTTPS au moins une fois, même si vous utilisez HSTS.Sans oublier quand / si l'en-tête expire.
#2
+13
PulpSpy
2011-01-18 09:51:24 UTC
view on stackexchange narkive permalink

Il peut être intéressant d'ajouter qu'il existe des outils automatisés pour faire exactement ce que les bonnes pratiques de l'OWASP indiquent: "un attaquant pourrait modifier la page au fur et à mesure qu'elle est envoyée à l'utilisateur et changer l'emplacement de soumission du formulaire ... "Le lien comprend une présentation de Black Hat sur l'attaque.

Prenez quelques heures pour vérifier les autres outils et articles de ce site, Moxie est vraiment un gars intéressant avec de grandes connaissances sur SSL et la sécurité en général.
#3
+10
Rory McCune
2011-01-18 16:39:36 UTC
view on stackexchange narkive permalink

Pour compléter les réponses déjà fournies. Il y a eu des cas pratiques où le fait d'avoir des pages de destination non HTTPS permet aux attaquants de modifier le site et d'obtenir les informations d'identification des utilisateurs. Cet exemple est le plus récent que j'ai vu. Dans ce cas, cela a été fait au niveau du FAI, mais cela pourrait également être fait par des fournisseurs de points d'accès sans fil ou par toute personne utilisant les outils appropriés pour mener une attaque Man-In-The-Middle.

#4
-3
symcbean
2011-01-18 17:05:06 UTC
view on stackexchange narkive permalink

Techniquement, c'est toujours sécurisé - votre navigateur devrait vous dire s'il n'aime pas le certificat après la poignée de main SSL mais avant d'envoyer des données HTTP, mais en tant qu'utilisateur, je me méfierais beaucoup de un site me demandant de fournir les détails d'authentification avant de passer au HTTPS - sans creuser et connaître le sujet, je ne sais pas avant d'avoir envoyé les informations si l'endroit où je les envoyais à est sécurisé (ou là où je m'attendais).

Même si je fais confiance au site, cette approche peut être sapée par une attaque MITM sur la page HTTP.

votre réponse contredit votre première phrase: que «techniquement c'est toujours sûr» ». Le problème est que «sécurisé» peut signifier plusieurs choses ici.
Mais bien sûr, techniquement, il n'est sécurisé que si le site est légitime et n'a pas été falsifié avant la saisie des informations d'identification, ce que vous ne pouvez pas vérifier si aucun certificat n'est visible, n'est-ce pas?
Non, techniquement, il n'est toujours pas sûr, du moins contre les attaques de l'homme du milieu. La page pourrait avoir été modifiée et envoyer votre mot de passe à Tombouctou. Les avertissements du navigateur ne sont ** pas ** efficaces pour arrêter de telles attaques. Votre dernière phrase est correcte, mais votre premier paragraphe est incorrect.
@Troy - «sécurisé» ne protège pas seulement la confidentialité du transport, son authentification, etc.


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