Quelle est la différence entre utiliser HSTS et faire une redirection 301?

Question

Si j'ai déjà effectué une redirection 301 de toutes les pages internes HTTP vers HTTPS, pourquoi devrais-je également utiliser HSTS?

Anders · Answer

Voyons d'abord le scénario avec une redirection 301. La victime envoie une demande à http://example.com (comme indiqué dans les commentaires, cela pourrait être dû à SSLStrip ou au fait que l'utilisateur vient de saisir example.com dans la barre d'URL et les navigateurs par défaut sur 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 existe 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 établie, et l'attaquant peut modifier ce trafic. Cependant, si vous aviez utilisé HSTS, le navigateur saurait (en supposant que la victime avait déjà visité le site) que la page devrait toujours être servie via HTTPS - aucune demande 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 en cache 301 réponses rend cela un peu plus compliqué dans la pratique. Pour plus d'informations à ce sujet, voir la bonne réponse de bonsaiviking ou cette question . L'histoire courte est que le 301 mis en cache peut aider un peu, mais ne vous emmènera pas tout le chemin que fait HSTS.)

bonsaiviking · Answer

HTTP Strict Transport Security (HSTS) est conçu pour la sécurité. HTTP 301 Déplacé en permanence est utilisé pour la redirection d'URL.

La redirection 301 est une partie importante 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 demande initiale lorsque l'utilisateur tape "example.com" dans son navigateur est envoyé en clair. Si cette demande initiale est faite sur un réseau hostile avec un homme au 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:

HSTS couvre tout le domaine. Une redirection 301 ne couvre qu'un chemin URI spécifique. Si un utilisateur est redirigé vers example.com/, puis une demande ultérieure à example.com/somepage utilisera toujours HTTP au départ et doit être redirigé à nouveau. Un site utilisant HSTS ne nécessite qu'une seule demande pour couvrir l'ensemble du site.
HSTS fonctionne même avec une connexion HTTPS initiale. Une redirection 301 mappe uniquement un URI en texte brut à un HTTPS, donc la visite du HTTPS ne confère directement aucune protection aux visites suivantes.
HSTS utilise un cache séparé avec un délai d'expiration séparé. Le cache 301 est souvent lié au cache de demande du navigateur, qui est conçu pour les performances. Si vous ne visitez pas une page pendant un certain temps, elle sera probablement supprimée du cache pour favoriser les sites les plus visités. Il peut même y avoir un âge maximum pour ce cache qui est de quelques semaines ou mois. Un correctif courant pour "le site ne fonctionne pas" indique à l'utilisateur "vider votre cache". Tout cela exposerait à nouveau l'utilisateur à la menace MITM. Les délais d'expiration HSTS sont généralement de l'ordre de plusieurs mois à plusieurs années, et le cache est généralement séparé, il ne peut donc pas être effacé facilement ou accidentellement.
HSTS peut être préchargé dans un navigateur par le fabricant. Google le fait avec son navigateur Chrome basé sur les en-têtes découverts lors de l'exploration Web et soumis directement à leur programme. Pour les sites préchargés, le navigateur n'aura jamais besoin de visiter via texte en clair en premier lieu; il peut toujours être supposé être HTTPS uniquement.

CBHacking · Answer

Tout d'abord, certains anciens navigateurs ne prennent pas en charge HSTS, vous devez donc rediriger HTTP vers HTTPS, définir l'indicateur secure sur tous les cookies, etc. Maintenant, cela étant dit ...

En plus des bonnes raisons énumérées ci-dessus, comme 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 les simples redirections ne le font pas.

Disons qu'un site est entièrement visité sur HTTPS. L'utilisateur est très prudent et ne demande que ce site via HTTPS. Aucune redirection n'est nécessaire. Il n'y a pas de HSTS, mais il n'y a pas non plus de lien 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 (s'il est présent) dans la page sans échappement approprié (XSS basé sur les cookies, rare mais rarement inconnu). L'attaquant ne peut pas réellement lire (et encore moins modifier) le trafic HTTPS, mais il veut vraiment accéder à la session de l'utilisateur sur ce site HTTPS. Ainsi, ils attendent que l'utilisateur visite un autre autre site via HTTP, et modifie la réponse de ce site pour inclure une demande invisible (peut-être un script src ) à http://securesite.com/ (votre site HTTPS uniquement, mais à la place via HTTP). Que se passe-t-il ensuite:

Si le site a une stratégie HSTS active dans le navigateur, le navigateur réécrit automatiquement la demande sous la forme https://securesite.com/ et l'attaquant ne peut pas lire ou modifier le trafic.
Si l'attaquant ne falsifie pas mais que le site n'a pas de HSTS, la demande s'éteint, obtient un 301 à https://securesite.com/, et la demande sort de nouveau via HTTPS.
- Cependant, tous les cookies pour securesite.com mais sans l'indicateur secure dessus seront inclus avec cette demande non sécurisée initiale. L'attaquant peut les lire même juste via l'écoute passive à ce point. 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 doit jamais être accessible via une connexion non sécurisée).
Si tous les cookies sont secure, 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 Set-Cookie en-tête de la réponse, mettant un cookie dans le navigateur de l'utilisateur qui sera envoyé lors de futures demandes à securesite.com, via HTTP ou HTTPS.

Avec l'hypothèse du vecteur XSS basé sur les cookies (ou toute autre chose où une attaque par implantation de cookies peut nuire), l'attaquant a réussi à attaquer un site auquel l'utilisateur a pris très soin d'accéder uniquement via HTTPS, juste car il n'utilisait pas HSTS et présentait une vulnérabilité qui serait impossible à exploiter sans une connexion non sécurisée.

SilverlightFox · Answer

L'essentiel à noter est que la même politique d'origine pour les cookies est plus laxiste que la même politique d'origine ailleurs. Autrement dit, il n'y a pas un seul canal sécurisé pour les cookies, ils sont de la même origine:

Client ----Plain HTTP----> Server Client ---------HTTPS----> Server

Bien sûr, le drapeau sécurisé peut être défini de sorte qu'une valeur de cookie peut être définie pour ne transférer que via HTTPS.

par exemple.

Set-Cookie: foo=bar; secure

Client --> HTTP (no cookies) --> Server Client --> 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 l'indicateur sécurisé.

par exemple. sur HTTP simple

Set-Cookie: foo=bar

Client --> HTTPS (Cookie: foo=bar) --> Server

Le serveur sera dans cette situation:

Ainsi, bien que les cookies définis par le serveur sur HTTPS ne soient pas reniflables, un MITM peut injecter ses propres valeurs dans une session "sécurisée". Cela est vrai même si vous n'avez pas de service HTTP ordinaire:

Client ----Plain HTTP----> No service Client ---------HTTPS----> Server

... car un MITM peut toujours générer une requête HTTP simple vers votre domaine et injecter le cookie:

Client ----Plain HTTP----> MITM --> No service Client ---------HTTPS-------------> Server

Cela peut conduire à certaines attaques si votre site présente des vulnérabilités qui ne pourraient pas être exploitées autrement:

Fixation de session: Comment les cookies non sécurisés ou non HTTP peuvent-ils affecter la sécurité d'un site Web HSTS?
Empoisonnement par les cookies XSS: cookie Flash et homme au milie

En plus de ce qui précède, les attaques de style ssltrip peuvent être effectuées sans HSTS. sslstrip s'appuie dans une certaine mesure sur l'utilisateur qui ne remarque pas qu'il n'y a pas de HTTPS.

Voir aussi cette réponse .