Si j'ai déjà effectué une redirection 301 de toutes les pages internes HTTP vers HTTPS, pourquoi devrais-je également utiliser HSTS?
Regardons d'abord le scénario avec une redirection 301. La victime envoie une requête à http://example.com (comme indiqué dans les commentaires, cela peut être dû à SSLStrip ou parce que l'utilisateur vient de saisir example.com dans le champ La barre d'URL et les navigateurs utilisent par défaut HTTP). S'il n'y a pas d'attaque MitM, ils obtiennent une réponse 301 et sont redirigés vers https://example.com . Mais s'il y a un MitM, l'attaquant peut simplement choisir de ne pas envoyer le 301, mais plutôt de servir une copie (éventuellement modifiée) du site via HTTP.
Le point faible ici est qu'une connexion HTTP initiale (sans TLS) est fait, et l'attaquant peut modifier ce trafic. Cependant, si vous aviez utilisé HSTS, le navigateur saurait (en supposant que la victime a déjà visité le site) que la page devrait toujours être servie via HTTPS - aucune requête HTTP n'aurait jamais été envoyée et le navigateur enverrait simplement une demande à https://example.com . L'attaquant ne peut pas MitM la connexion TLS, donc l'attaque est empêchée.
(Le fait que les navigateurs mettent 301 réponses en cache rend cela un peu plus compliqué dans la pratique. Pour plus d'informations à ce sujet, voir bonsaiviking's great répondez ou à cette question. En bref, le 301 mis en cache peut aider un peu, mais pas tout ce que fait HSTS.)
HTTP Strict Transport Security (HSTS) est conçu pour la sécurité. HTTP 301 déplacé de manière permanente est utilisé pour la redirection d'URL.
La redirection 301 est un élément important du déploiement d'un site Web HTTPS. Dans le cadre du protocole HTTP, il est pris en charge par plus de navigateurs que HSTS. Il sert de moyen principal pour mettre à niveau une connexion en texte brut vers HTTPS, mettre à jour les index de recherche et éviter la pourriture des liens.
Dans de nombreux cas, ces deux méthodes ont la même faiblesse: la requête initiale lorsque l'utilisateur tape "example.com" dans son navigateur, il est envoyé en clair. Si cette demande initiale est faite sur un réseau hostile avec un homme du milieu actif (MITM), la réponse peut être interceptée et la connexion ne sera pas mise à niveau vers une connexion sécurisée.
Cependant, Il existe de nombreuses raisons pour lesquelles HSTS est important et une grande amélioration de la sécurité par rapport à une redirection 301 standard:
example.com/ , une demande ultérieure à example.com/somepage utilisera toujours HTTP au départ, et devra être redirigée. Un site utilisant HSTS ne nécessite qu'une seule demande pour couvrir l'intégralité du site. Tout d'abord, certains anciens navigateurs ne prennent pas en charge HSTS, vous devez donc toujours rediriger HTTP vers HTTPS, définir l'indicateur secure sur tous les cookies, etc. Maintenant, cela dit. .
En plus des bonnes raisons énumérées ci-dessus, puisque vaincre les attaques de type SSLStrip est l'un des principaux objectifs de HSTS, il existe une autre attaque contre laquelle HSTS protège, mais pas les simples redirections.
Disons qu'un site est entièrement visité sur HTTPS. L'utilisateur est très prudent et ne demande ce site que via HTTPS. Aucune redirection nécessaire. Il n'y a pas de HSTS, mais il n'y a pas non plus de liens vers le site via HTTP non sécurisé, donc tout le trafic avec le site est crypté.
Cependant, supposons que le site présente une vulnérabilité de sécurité où il reflète un cookie spécifique (si présent) dans la page sans échapper correctement (XSS à base de cookies, rare mais à peine inouï). L'attaquant ne peut pas réellement lire (et encore moins modifier) le trafic HTTPS, mais il souhaite vraiment accéder à la session de l'utilisateur sur ce site HTTPS. Ainsi, ils attendent que l'utilisateur visite un autre site via HTTP, et modifient la réponse de ce site pour inclure une requête invisible (peut-être un script src) vers http: // site sécurisé. com / (votre site HTTPS uniquement, mais via HTTP à la place). Que se passe-t-il ensuite:
https://securesite.com/ et l'attaquant ne peut lire ou modifier aucun trafic. https: / /securesite.com/ , et la requête est à nouveau envoyée via HTTPS. secure seront inclus avec cette demande initiale non sécurisée. L'attaquant peut les lire même simplement via une écoute passive à ce stade. C'est mauvais (et c'est une raison pour laquelle les cookies sensibles doivent toujours avoir l'indicateur secure même si le site ne devrait jamais être accédé via une connexion non sécurisée). sécurisés , cela rend cette attaque inutile. L'attaquant devra à nouveau trafiquer. Ils peuvent falsifier ou modifier la réponse à la demande non sécurisée. Dans ce cas particulier, l'attaquant ajouterait un en-tête Set-Cookie à la réponse, plaçant un cookie dans le navigateur de l'utilisateur qui sera envoyé lors de futures requêtes à securesite.com, via HTTP ou HTTPS. Avec l'hypothèse d'un vecteur XSS basé sur les cookies (ou toute autre chose où une attaque de plantation de cookies peut nuire), l'attaquant a réussi à attaquer un site avec lequel l'utilisateur a été très prudent pour accéder uniquement via HTTPS , simplement parce qu'il n'utilisait pas HSTS et avait une vulnérabilité qui serait impossible à exploiter sans une connexion non sécurisée.
''). La chose essentielle à noter est que la politique de même origine pour les cookies est plus laxiste que la politique de même origine ailleurs. Autrement dit, il n'y a pas un seul canal sécurisé pour les cookies, ils ont la même origine:
Client ---- Simple HTTP ---- > ServerClient -------- -HTTPS ---- Serveur > Bien sûr, le drapeau sécurisé peut être défini afin qu'une valeur de cookie puisse être définie pour ne transférer que via HTTPS.
par exemple p>
Set-Cookie: foo = bar; secure
Client --> HTTP (pas de cookies) --> ServerClient --> HTTPS (Cookie: foo = bar) --> Server Cependant, il n'y a aucun moyen pour le serveur de savoir si un cookie a été défini avec le drapeau sécurisé.
par exemple sur HTTP simple
Set-Cookie: foo = bar
Client --> HTTPS (Cookie: foo = bar) --> Server Le serveur sera dans cette situation:
Donc, bien que les cookies définis par le serveur sur HTTPS ne sont pas détectables, un MITM peut injecter ses propres valeurs dans une session «sécurisée». Ceci est vrai même si vous n'avez pas de service HTTP simple:
Client ---- HTTP ordinaire ---- > Aucun serviceClient --------- HTTPS ---- Serveur > ... car un MITM peut toujours générer une simple requête HTTP vers votre domaine et injecter le cookie:
Client ---- Plain HTTP ---- > MITM --> Pas de serviceClient --------- HTTPS ------------- Serveur > Cela peut entraîner des attaques si votre site présente des vulnérabilités qui ne pourraient autrement pas être exploitées:
Aussi comme ci-dessus, les attaques de style ssltrip peuvent être effectuées sans HSTS. sslstrip repose dans une certaine mesure sur le fait que l'utilisateur ne remarque pas qu'il n'y a pas de HTTPS.
Voir également cette réponse.
HSTS utilise une redirection 307 côté client en bac à sable, donc il n'atteint même pas le serveur tant qu'il n'est pas en mode https explicite. Une redirection 301, d'autre part, est côté serveur, prend des ressources, du temps à compléter, etc. En outre, une 301 empile votre nombre de redirection [chaînée], qui est généralement attribuée à la dilution du référencement.
Donc HSTS est généralement le meilleur choix en raison de sa nature côté client + bac à sable. Mais, il y a un «danger» à cela avec un TTL très long sur le cache. Lorsqu'un SSL expire ou si vous souhaitez revenir en arrière, les utilisateurs du mode http seront verrouillés. Cela est dû au fait que le TTL HSTS mis en cache est / ne recherchera que https, mais les navigateurs ne verront aucun site avec un certificat expiré. Alors ne le laissez jamais expirer ou changer de mode sans régler le temps de cache HSTS sur 0 dans les semaines (ou mois) précédant le changement :) Vous n'avez pas à vous en soucier avec 301 car ce n'est pas le navigateur qui prend la décision de rediriger ou non - les utilisateurs ne seront pas verrouillés si vous effectuez le changement côté serveur.
Puisque HSTS nécessite toujours une redirection la première fois que chaque utilisateur visite votre site Web (à moins que nous ne soyons si sûrs de l'absence d'erreurs qu'un préchargement irréversible via l'enregistrement peut être osé), c'est une question piège. Il n'y a essentiellement aucune différence entre l'utilisation de l'en-tête HSTS et l'utilisation d'un en-tête de redirection.
La seule bonne solution à laquelle je puisse penser est d'ajouter un type d'enregistrement ou un indicateur à chaque enregistrement de zone DNS pour spécifier "ce domaine prend en charge HTTPS ". Ensuite, il n'y a pas besoin de HSTS ou de redirection. Le navigateur sait déjà que https est pris en charge (à partir de sa recherche DNS), il peut donc (à moins d'être annulé par l'utilisateur) réécrire le http de l'utilisateur en https avant même d'envoyer la première requête au serveur distant.