Est-ce toujours vulnérable aux attaques MIM?

Oui, c'est vrai, car vous utiliseriez probablement des cookies de session qui pourraient être facilement reniflés via un plugin de navigateur comme Firesheep ou Man-in-the-Middle.

Quelles sont les précautions?

La meilleure pratique de nos jours est de faire exécuter toute votre application via HTTPS car:

• sécurisé les cookies ne fonctionnent pas dans un environnement mixte
• Les attaques MITM do fonctionnent dans un environnement mixte
• garantissant l'authenticité de votre site Web à ses utilisateurs ne fonctionne pas dans un environnement mixte
• pas besoin pour penser aux ressources HTTP dans une page HTTPS et aux alertes de navigateur laides

Pour assurer HTTPS sur tout le site:

• créez 2 configurations d'hôtes virtuelles , un pour http: et un pour https:
• dans votre configuration http, utilisez une redirection de http: // site / resource vers https: // site / ressource comme seul modèle dans cette configuration, donc si quelqu'un tape i n http: // site / somepath il sera toujours redirigé vers le site sécurisé
• dans votre configuration https, utilisez un en-tête HTST pour vous assurer (basé sur le navigateur) que votre utilisateur visite toujours votre site via HTTPS

Tout le reste, comme le cryptage de la page de connexion uniquement, est obsolète; rechercher "firesheep"

Oui, vous êtes vulnérable aux attaques MITM car vous débutez avec une application Web non chiffrée. C'est là que l'attaque a lieu, car l'attaquant pourrait modifier toutes les références à https://secure.bank.com et les remplacer par http://secure.bank. com . L'attaquant intercepterait alors vos données et relayerait le contenu vers la connexion sécurisée réelle à https://secure.bank.com

Il est fortement suggéré de forcer SSL à partir du au tout début de la session, et vous devez vous assurer de n'annoncer que l'URL sécurisée.

Après avoir visité http://normal.bank.com , un attaquant peut remplacer tous les liens vers https://secure.bank.com par des liens vers http://secure.bank.com . Lorsque l'utilisateur clique sur http://secure.bank.com , le MITM se connecte volontiers au serveur via HTTPS et renvoie le contenu au client via HTTP. Quelles que soient les précautions de redirection utilisées ici, toute la redirection peut être empêchée par le MITM.

En conclusion, oui, vous êtes toujours vulnérable aux attaques MITM.

Je vais renverser la tendance ici et dire qu'il est acceptable de rediriger comme ça.

Il est vrai qu'un utilisateur est vulnérable au MITM s'il accède à http: // secure.bank.com/ et continuer à utiliser le site sans autre vérification des certificats, des URL, etc.

Cependant, il s'agit d'un problème de comportement de l'utilisateur, et non de quelque chose que vous pouvez réparer le serveur -side.

Réfléchissons une minute à la manière dont vous pourriez essayer de résoudre ce problème côté serveur. Plutôt que d'émettre une redirection, vous pouvez afficher une page d'information, peut-être avec un avertissement clairement formulé "Pour accéder à ce site en toute sécurité, vous devez utiliser https://secure.bank.com/" Ou vous pouvez avoir le Le serveur Web n'écoute que sur le port 443 et rejette le port 80.

Que se passe-t-il maintenant si un attaquant a le contrôle total du réseau d'un utilisateur? Lorsque l'utilisateur accède à http://secure.bank.com/, l'attaquant le redirige vers https://secure.bank.com.attacker.com/ et présente une page de phishing. Ou peut-être qu'ils insèrent une page de hameçonnage directement dans http://secure.bank.com/ De toute façon, un utilisateur expérimenté et alerte pourrait le détecter, mais de nombreux utilisateurs continueront.

Le comportement du vrai http://secure.bank.com/ ne fait aucune différence - l'attaquant peut faire ce qu'il veut.

Donc, en fin de compte, c'est un problème de formation des utilisateurs. Et le comportement du site peut influencer cela. La grande majorité des fois qu'un utilisateur visite le site, il visitera le site réel et non une attaque MITM. Si le site les redirige automatiquement, cela ne les décourage pas d'utiliser l'URL http à l'avenir. S'ils reçoivent un message d'avertissement, ou si le site ne fonctionne tout simplement pas, ils apprendront rapidement à utiliser le https par défaut.

Mais dans quelle mesure êtes-vous responsable, en tant qu'opérateur de site, de former vos utilisateurs de cette manière? La réalité est que la grande majorité des sites redirigent de http vers https de cette manière. D'un point de vue commercial, pourquoi rendre votre site plus difficile à utiliser qu'un concurrent? Si ce n'est que vous qui faites cette position, allez-vous vraiment avoir un effet sur le comportement général des utilisateurs?

Pour ces raisons, dans l'ensemble, je recommande que la plupart des sites redirigent de http vers https de cette manière.

Pour verrouiller cela autant que possible, je vous recommande de configurer la redirection afin que http://secure.bank.com/ redirige vers https: // secure.bank.com/ - suppression du reste de l'URL.

Cela n'a pas été explicitement mentionné jusqu'à présent, donc cette réponse tardive. Les sites Web basculant entre HTTP et HTTPS sont inévitablement enclins à la bande SSL . Une bonne explication que vous pouvez trouver ici:

Présentation SSL-strip de Moxie Marlinspike

Quelques points importants:

• C'est la première demande qui fait la différence. Chaque fois que l'utilisateur commence avec HTTP comme première page, la bande SSL peut parler à l'utilisateur avec HTTP et au site avec HTTPS. Un changement de site empêchera l'utilisateur de choisir HTTPS pour la première demande.
• C'est là que l'en-tête HSTS entre en jeu. Si vous avez déjà visité le site plus tôt à partir d'une connexion sécurisée, l'en-tête indiquera au navigateur appelez le site avec HTTPS uniquement pour les demandes futures. Si vous visitez le site pour la première fois, l'en-tête HSTS ne peut pas vous aider.
• Si l'utilisateur s'en soucie, il peut commencer par HTTPS (en tapant l'url avec https: // dans la barre du navigateur), cela fait Strip SSL impossible sur les sites SSL uniquement.

J'ai écrit un article de blog à ce sujet il y a quelques mois. Dans mon article de blog, j'ai montré comment la redirection du trafic de http vers https pouvait potentiellement être dangereuse selon le mécanisme sélectionné. J'ai proposé HSTS (HTTP Strict Transport Security).

http://blog.michaelhidalgo.info/2013/09/redirecting-http-traffic-to-https-why.html