Comment empêchez-vous d'envoyer des données de cookies sur HTTP la première fois?
Vous pouvez utiliser HSTS pour dire au navigateur de toujours utiliser HTTPS dans les demandes futures.
Vous pouvez utiliser le drapeau Cookie Secure qui désormais ne pourra envoyer que des cookies via HTTPS.
Vous pouvez utiliser la redirection basée sur DNS mais uniquement après que la demande HTTP y soit arrivée.
Ma question est de savoir comment vous assurer que l'utilisateur visite toujours le site en HTTPS et n'envoie jamais de données via HTTP, même la première fois.
Modifier:
Étant donné le manque de solution à cela, je pense que les navigateurs devraient d'abord envoyer automatiquement la demande https par défaut et cela ne fonctionne pas, puis rétrograder.
En résumé des commentaires (et en remplaçant ma réponse précédente): tant que sslstrip est possible, l'attaquant peut se faire passer pour l'utilisateur et contrôler la session tandis que le navigateur pense que l'utilisateur contrôle la session. Seul HSTS peut empêcher sslstrip et seul le préchargement HSTS peut empêcher sslstrip à la première demande (avant d'obtenir un en-tête HSTS).
Ainsi, la précharge HSTS devrait être la voie à suivre comme indiqué correctement dans la réponse de Benoit Esnard .
Le problème est que la précharge HSTS peut prendre des mois pour être disponible pour un nouveau domaine car une liste mise à jour n'est livrée qu'avec une nouvelle version du navigateur (au moins dans le cas de Google Chrome).
En d'autres termes: il n'y a pas de solution qui puisse être mise en œuvre en peu de temps.
Soumettez votre site Web à la liste de préchargement HSTS .
La liste de préchargement HSTS est une liste de noms d'hôtes intégrés dans les navigateurs, leur permettant de savoir quels sites Web doivent être explorés uniquement en HTTPS, empêchant ainsi toute demande non HTTPS.
Ce que vous décrivez est appelé Session Fixation Attack (lien Wikipedia) .
En bref, le problème est que l'attaquant peut vous fournir un cookie d'identification de session. Vous vous connectez à l'aide de ce cookie et le serveur associera votre identité à ce cookie.
L'attaquant connaît toujours votre cookie d'identification de session et peut prétendre être vous avec le serveur. Attaque terminée.
Pour se défendre contre cela, le serveur doit changer le cookie d'identification de session lorsque quelqu'un se connecte. L'attaquant se retrouve avec un cookie périmé sans valeur et ne peut rien faire.
Tous les cadres Web ne vous permettent pas de modifier le cookie de session. En cas de problème, vous pouvez utiliser un autre cookie à cet effet, un "cookie authentifié" distinct que le framework ne connaît pas. Ce cookie doit également être modifié à chaque connexion.
Étant donné qu'il n'y a pas de moyen complet d'empêcher les clients d'essayer de se connecter à HTTP, éventuellement avec des cookies ... notre défi est de trouver des moyens de réduire la fréquence de ces événements.
Une approche consiste à ne pas prendre en charge HTTP du tout. Laissez toutes les requêtes HTTP expirer (pas de redirection, rien). Cela réduit les chances que d'autres sites établissent un lien vers votre adresse HTTP, car ces liens ne fonctionneront pas. Au fil du temps, j'espère que tous ceux qui ont un lien vers votre site se connecteront directement à HTTPS.
Vous ne pouvez pas empêcher les cookies d'être envoyés sur HTTP la première fois, mais vous pouvez prendre des mesures pour minimiser les dommages qui pourraient en résulter. Le principe de base est que vous n'honorez jamais, jamais rien soumis via HTTP, et chaque fois que vous recevez des informations sensibles en texte clair, vous traitez ces informations comme compromises.
Configurez votre site pour rediriger de HTTP vers HTTPS et commencez à envoyer des en-têtes Strict-Transport-Security. (Vous n'avez pas besoin de précharger tant que vous n'êtes pas bon et prêt; ce que je vais dire fonctionnera malgré tout.)
Ensuite, chaque fois que vous voyez des cookies envoyés via HTTP en texte clair, invalidez tous ces cookies côté serveur. N'essayez pas de les expulser du pot de cookies du navigateur à ce stade, car il n'est pas garanti de fonctionner pour plusieurs raisons (une réponse HTTP en texte clair ne peut pas manipuler les cookies balisés Secure, les navigateurs plus anciens peuvent ignorer max-age = 0 , l'homme du milieu peut supprimer complètement Set-Cookie afin de garder la victime utilisant le cookie compromis). Mais ne les respectez pas lorsqu'ils apparaissent dans une demande HTTPS ultérieure. À ce stade (c'est-à-dire uniquement lorsqu'un canal sécurisé est établi), émettez un nouveau jeton de session et demandez à l'utilisateur de se reconnecter.
De même, si vous voyez votre formulaire de connexion soumis en texte clair, n'invalidez pas simplement le cookie de session, verrouiller le compte . Ne pas rediriger le formulaire de récupération de compte, de connexion ou d'enregistrement de HTTP vers HTTPS; à la place, émettez un message d'erreur, demandant à l'humain de corriger l'URL à la main (c'est comme un captcha, mais c'est pour contourner la réécriture d'URL dans sslstrip ;-). Et toute page qui ne devrait être accessible qu'aux utilisateurs connectés doit rediriger vers la page d'accueil, pas vers HTTPS-lui-même, lorsqu'elle est accessible via du texte en clair.
De plus, assurez-vous que vos cookies de session sont à la fois infalsifiables et sans signification . La plupart des frameworks Web le feront automatiquement pour vous de nos jours, mais si vous n'en avez pas, la construction la plus simple qui fonctionnera est: chaque cookie de session est un grand nombre aléatoire (64 bits pourraient suffire, 128 est certainement suffisant), généré par un RNG cryptographiquement sécurisé , plus un code d'authentification du message signant ce numéro. Vous pouvez utiliser un MAC symétrique pour cela, car le cookie doit uniquement être authentifié par le site, qui est la même entité qui a émis le MAC, il connaîtra donc le même secret à chaque fois. Si un cookie arrive avec un MAC invalide, ignorez-le , peu importe comment vous l'avez obtenu - prétendez que vous ne l'avez jamais obtenu du tout. (Cela remplace même la règle concernant l'invalidation des cookies qui arrivent via HTTP. Vous ne voulez pas que l'attaquant puisse forcer la déconnexion des gens en forgeant des demandes.) Mais si le MAC est valide, vous utilisez alors le nombre aléatoire comme clé d'une table de base de données enregistrant toutes les informations réelles associées à une session utilisateur.
Il est également recommandé de ne pas émettre de cookies du tout jusqu'à ce que quelqu'un essaie de se connecter. Cela rend beaucoup plus difficile pour un MITM de mettre la main sur un cookie valide, et cela vous permet également de vous conformer plus facilement au RGPD.
Après avoir lu la discussion sur les autres réponses, je me rends compte maintenant OP est concerné par un scénario très particulier: un nouvel utilisateur sur le site y accède pour le très première fois par un homme du milieu, qui met fin à HTTPS, supprime HSTS et réécrit tous les liens, et relaie le site non chiffré au nouvel utilisateur hypothétique. Contre cela, en effet, la seule chose qui peut éventuellement aider est la précharge HSTS. En l'absence de précharge HSTS, le compte du nouvel utilisateur sera "né compromis", pour ainsi dire, et l'attaquant saura tout à ce sujet: non juste le cookie de session, mais le nom d'utilisateur et le mot de passe, et l'adresse e-mail utilisée pour la récupération du compte, et chaque bit d'informations personnelles que la victime a entrées. C'est méchant et, hélas, plus plausible que vous ne le pensez.
Mais si vous avez une seule chance d'interagir avec l'utilisateur sur un canal qui n'est pas activement trafiqué, vous pouvez pousser HSTS et sécuriser les cookies de session et tous les conseils ci-dessus seront utiles.