Sécurité d'une redirection initiale de http://example.com vers https://example.com
Supposer que http://example.com/<foo> redirige systématiquement vers https://example.com/<foo>. J'entre http://example.com dans la barre d'URL de mon navigateur, je vois une page se charger et la barre d'URL affiche maintenant exactement https://example.com/ (pas de hack Unicode, pas de hack d'espaces, etc.). Je vérifie que c'est le cas (la plupart des utilisateurs ne le feront pas, mais supposons que dans ce cas, l'utilisateur l'a fait) Supposons en outre que mon navigateur n'est pas vulnérable à falsification de la barre d'URL . Supposez également que le certificat SSL est valide.
Dans cette situation, puis-je avoir confiance que ma session n'est désormais plus vulnérable à aucune attaque d'homme au milieu? Un MITM sur la connexion HTTP initiale aurait-il pu injecter quelque chose - un cookie, une trame cachée, quoi que ce soit qui compromettrait la session HTTPS apparente suivante?
Ceci est un sous-cas de la façon dont la sécurité redirige l'utilisateur de http://normal.bank.com vers https://secure.bank.com ?, je suis après plus de détails pour ce cas spécifique.
En plus des excellentes réponses de @ GZBK et @ Adnan, une autre chose à laquelle j'ai pensé est le cas où l'application est vulnérable à XSS à la sortie d'un valeur du cookie.
Disons normalement que la valeur du cookie est sortie non encodée, mais comme le cookie était normalement défini sur HTTPS et ne serait pas soumis au MITM, ce n'était pas un danger car l'utilisateur ne pouvait que s'attaquer. Cependant, si la requête HTTP a été interceptée et que le cookie a été empoisonné avec un exploit pour cette vulnérabilité XSS , cela pourrait être un vecteur d'attaque possible dans ce scénario.
Bien sûr, ce n'est pas la demande non HTTPS dont une redirection est vulnérable car ce cookie pourrait être défini même si "example.com "n'a pas écouté du tout sur le port 80: un attaquant pourrait MITM toute autre requête HTTP de la victime, redirigez-la vers" http://example.com "que l'attaquant intercepte également et renvoie la réponse pour rediriger l'utilisateur vers son site Web d'origine, mais uniquement après le" example.com "Le cookie a été empoisonné.
puis-je avoir confiance que ma session n'est désormais plus vulnérable à aucune attaque d'homme au milieu?
La seule façon vraiment sécurisée de naviguer sur un réseau non fiable est de désactiver tous les protocoles du navigateur autre que HTTPS (par exemple, configurer un proxy local mais configurer le navigateur pour utiliser un port non valide pour tous les protocoles autres que HTTPS). HSTS peut vous aider, mais si la première demande est interceptée (par exemple, en utilisant la technique décrite ici avant même d'avoir pensé à visiter "example.com ") vous seriez toujours vulnérable.
Mise à jour ci-dessous par rapport à la nouvelle question dans le commentaire:
[J'ai oublié de saisir le commentaire sur la prime] Je demande du point de vue d'un utilisateur (bien qu'il soit intéressant de savoir ce que le site/l'application devrait également faire). Dans quelles circonstances taper example.com dans la barre d'URL du navigateur me dirige-t-il directement vers https://example.com/ ? Dans quelles circonstances taper http://example.com/ me dirige-t-il directement vers https://example.com/ ? S'il y a une demande pour http://example.com/ d'abord, quelles mauvaises choses peuvent arriver, et comment en tant qu'utilisateur puis-je savoir si de mauvaises choses se produisent? - Gilles
S'il y avait un enregistrement HSTS actif pour "example.com "(soit pré-chargé ou si l'utilisateur avait déjà visité) et l'utilisateur a tapé "example.com" ou "http://example.com" dans leur barre d'adresse, ils iraient directement à "https://example.com" sans aucune demande sur HTTP.
Lorsqu'une application Web émet une stratégie HSTS aux agents utilisateurs, les agents utilisateurs conformes se comportent comme suit: Transformez automatiquement tous les liens non sécurisés référençant l'application Web en liens sécurisés. (Par exemple, http://example.com/some/page/ sera modifié en https://example.com/some/page/ avant d'accéder au serveur .) Si la sécurité de la connexion ne peut pas être assurée (par exemple, le certificat TLS du serveur est auto-signé), afficher un message d'erreur et ne pas autoriser l'utilisateur à accéder à l'application Web.
S'il n'y avait pas HSTS enregistrement et l'utilisateur a tapé "example.com" ou "http://example.com" dans leur barre d'adresse, une demande non sécurisée doit d'abord être adressée à "http://example.com "qui répondrait normalement par" Location: https://example.com/ ". Cela entraînera le navigateur à charger l'URL HTTPS. Si l'utilisateur voulait s'assurer que rien n'avait été injecté ou modifié et que tout ce qui s'était passé était que l'en-tête" Location "était retourné, il devrait effacer toutes les informations d'état. La procédure à suivre doit être la suivante:
- Fermez toutes les autres fenêtres et tous les onglets du navigateur - cela garantira qu'aucune autre requête HTTP ne sera MITM et redirigée vers "
example.com". - Désactivez JavaScript dans leur navigateur. Cela garantira qu'aucun script en cours d'exécution ne définit des cookies sur un intervalle. Par exemple, s'il y avait une vulnérabilité XSS via une valeur de cookie, le script injecté pourrait garantir que la valeur du cookie reste définie en la réinitialisant toutes les quelques secondes. AKA un cookie zombie .
- Effacer les cookies, tout stockage local et toutes les données de plug-in de navigateur (par exemple, Flash local/Silverlight). Cela supprimera la plupart des informations d'état du site.
- Appuyez sur Actualiser dans le navigateur. Cela garantira que la charge actuelle de la page n'était pas un POST car l'utilisateur recevrait un message d'avertissement. Le POST peut avoir injecté du contenu dans la page s'il y en a) toutes XSS vulnérabilités.
- Réactivez JavaScript si nécessaire.
Évidemment, cela demande beaucoup de travail et il peut être plus facile pour eux d'utiliser simplement la technique de proxy décrite ci-dessus pour désactiver HTTP et démarrer avec un navigateur propre (par exemple, une nouvelle session Incognito).
Si un utilisateur navigue sur un réseau non fiable, il ne peut jamais être sécurisé à 100%. Il n'y a pas de vérification facile de la falsification à moins que tout ne soit dans un état connu (d'où le fait de partir d'un état propre/HTTPS ou de supprimer toutes les informations d'état). Oui, ils pouvaient vérifier manuellement les cookies, mais avec des techniques intelligentes, un attaquant pourrait effacer le cookie une fois le script intégré à la page.
À ma connaissance, il existe deux vulnérabilités:
Le indicateur sécurisé n'est pas défini. La requête HTTP initiale entraînera une fuite du cookie de session à partir d'une session créée par l'instance à
http://example.comou d'une session précédente créée par l'instance àhttps://example.com. Le même identifiant de session divulgué sera réutilisé -> L'attaquant aura accès à la session.La requête HTTP initiale est interceptée et la réponse est remplacée par une qui plante un cookie avec un identifiant de session pour une session démarrée par l'attaquant. Les demandes ultérieures réutiliseront le même cookie. Il s'agit d'une forme de attaques par fixation de session .
Dans les deux cas, lorsqu'il atteint l'instance HTTPS, le serveur n'a aucun moyen de savoir s'il doit invalider la session précédente ou non, car la session peut être la session légitime démarrée par l'utilisateur.
La seule solution que je vois ici est d'invalider et de recréer la session lorsqu'une demande est faite à https://example.com, puis utilisez des jetons cryptographiquement puissants en plus du cookie de session avec les requêtes suivantes. Le jeton doit être utilisé une seule fois et une seule fois.
Comme mentionné ci-dessus, tous les cookies doivent être signalés comme sécurisés ( Owasp ), mais aussi si vous vous attendez à ce que vos utilisateurs accèdent à votre site uniquement via SSL, vous devez activer HTTP Strict Transport Security (HSTS - - Wikipedia ).
Le premier s'assurera qu'aucun cookie ne sera envoyé sur une connexion HTTP claire, le second s'assurera que tout navigateur compatible utilisera toujours, après un premier accès initial, HTTPS pour accéder au site Web (même lorsque l'utilisateur tape HTTP, le navigateur le remplacer automatiquement par HTTPS sans envoyer de requête HTTP au serveur).
Depuis la demande initiale a été envoyée via HTTP; il existe un grand nombre de vecteurs d'attaque possibles qui ne dépendent pas des cookies ou de l'état de session et ne seraient pas affectés par une redirection ultérieure vers HTTPS, même avec un en-tête HSTS fourni par le serveur.
Bien que je ne sois pas un spécialiste de la sécurité Web à temps plein, voici une liste des attaques possibles rendues possibles lorsqu'un attaquant est en mesure de MITM la requête HTTP d'origine.
1) Envoyez des redirections 301/302 vers des URL intermédiaires pour configurer/installer des logiciels malveillants en dehors du navigateur. Cela peut inclure des enregistreurs de frappe, etc. Très précieux car l'attaquant peut "sélectionner" les victimes qui se rendent sur un site d'intérêt. Lorsque le malware est déployé sur la cible, une redirection finale du navigateur est envoyée comme prévu au client et le film continue comme si de rien n'était.
2) Utilisez le même véhicule pour attaquer le navigateur lui-même. Il est possible ici pour l'attaquant d'effectuer des actions spécifiques au navigateur, comme l'installation d'un plug-in malveillant.
3) Comme ci-dessus, mais exploitez tous les trous disponibles pour changer la configuration du navigateur. Cela pourrait être utilisé pour permettre la fuite d'informations via un canal secret comme des indices de recherche ou la complétion de mots clés. Ou combinez cela avec l'option 1 et configurez le navigateur pour proxy SSL via le code s'exécutant localement.
4) Chargez la page SSL cible dans une iframe et exploitez les faiblesses XSS afin d'obtenir et d'exploiter les informations d'identification de session une fois la victime connectée.
Il existe un large éventail de difficultés dans les scénarios ci-dessus et ils reposent tous plus ou moins sur des faiblesses dans des versions de navigateur particulières. Beaucoup de scénarios peuvent être plus difficiles que d'autres vecteurs d'attaque plus faciles. Il existe l'utilité d'employer des exploits ciblés en fonction des informations disponibles dans les en-têtes de la demande d'origine, comme user-agent, qui pourraient être attrayants.
Je suis sûr qu'il y a d'autres grandes catégories d'attaques qui me manquent mais c'est un début d'exposition qu'une première session HTTP à HTTPS peut ouvrir.
En partant du principe que la connexion SSL a été établie avec le domaine correct (et en supposant que ni votre serveur ni le navigateur ne présentent de vulnérabilités), l'utilisateur a, via votre certificat SSL et ses certificats racine de confiance, vérifié que la page qu'il a chargée à partir de votre serveur est arrivé sans falsification.
Je vois les pièges suivants:
Une attaque d'homme au milieu est évidemment possible si l'intercepteur peut forger votre certificat SSL. Donc, si vous l'avez partagé (avec votre CDN? Avec l'administrateur escroc de votre hébergeur? Avec le collègue qui est légalement interdit d'admettre qu'il a été assigné à comparaître pour les clés?), C'est en fait un vecteur d'attaque possible. Cela peut également arriver si vous générez des clés faibles en premier lieu (peut-être que votre système était faible en entropie ou utilisait un générateur de nombres aléatoires cassé?).
Aucune des autorités de certification racine auxquelles le navigateur est configuré pour approuver ne peut être compromise. Notez qu'il y en a généralement beaucoup et qu'un seul compromis est requis pour l'homme du milieu pour forger un certificat SSL apparemment valide pour votre domaine. Notez également que certains utilisateurs peuvent être au gré de leur fournisseur qui peut (comme Microsoft) pousser de nouveaux certificats d'autorité de certification racine à la demande, autorisant théoriquement toute attaque d'homme de milieu (légale?) Que Microsoft (ou l'une des autorités de certification) ) peut être persuadé de soutenir. Nous pouvons, bien sûr, espérer que seuls les gentils ont autant de pouvoir sur les sociétés.
Même des vulnérabilités apparemment indépendantes peuvent évidemment nier tout l'argument, même celles qui peuvent être appelées une fonctionnalité plutôt qu'un bug: imaginez que l'homme du milieu sert initialement une page Web sur HTTP qui amène le navigateur à passer en affichage plein écran, et imite ensuite une fenêtre de navigateur typique. Votre hypothétique utilisateur super-intelligent va-t-il remarquer que la barre d'adresse et son contenu ne sont qu'une émulation élaborée de la barre d'adresse de son navigateur ...?