23 Septembre 2022

Qu'est-ce que HSTS, HTTP Strict Transport Security ?

HTTP Strict Transport Security est un mécanisme de politique de sécurité Web qui permet aux sites Web de se déclarer accessibles uniquement via des connexions sécurisées.

HSTS
Print Friendly, PDF & Email

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité Web qui permet aux sites Web de se déclarer accessibles uniquement via des connexions sécurisées. Cela permet de protéger les sites Web et les utilisateurs contre les déclassements de protocole et les attaques de piratage de cookies.

Pourquoi le HSTS a-t-il été introduit ?

HTTP est utilisé sur divers transports, généralement le protocole TCP (Transmission Control Protocol).

Cependant, TCP ne fournit pas l'intégrité de l'hôte, la confidentialité ou la protection de l'identification sécurisée.

Cela a conduit au développement de Secure Sockets Layer (SSL) et de son successeur Transport Layer Security (TLS). SSL / TLS fournit une couche de cryptage entre les protocoles d'application et TCP, communément appelée HTTPS.

En général, les agents utilisateurs (tels que les navigateurs Web) utiliseront diverses politiques de sécurité locales pour décider comment interagir avec un hôte, sur la base d'une négociation entre le serveur, les préférences de l'utilisateur et leur méthode de communication (HTTP ou HTTPS).

Cependant, certains agents utilisateurs permettent aux utilisateurs de choisir de continuer à interagir avec un site Web lorsqu'ils ne sont pas en mesure d'établir une connexion sécurisée. Cela peut se produire lorsque la chaîne de confiance d'un certificat TLS n'est pas validée, lorsqu'elle a expiré ou lorsque le nom de domaine de l'hôte TLS s'affiche de manière incorrecte dans le certificat TLS.

Ce comportement est appelé insécurité de clic.

Tout en offrant aux utilisateurs la possibilité de continuer à utiliser un site Web malgré le fait que l'absence de HTTPS puisse satisfaire les utilisateurs, il peut introduire des vecteurs d'attaque qui exposent les utilisateurs à certains types de cyberattaques, en particulier les attaques de l'homme du milieu. attaques), les attaques de rétrogradation et les attaques de détournement de session.

SSL-stripping

Étant donné que HSTS permet aux sites Web de déclarer qu'ils ne sont accessibles que via une connexion sécurisée, ils peuvent empêcher les utilisateurs de s'y connecter via n'importe quelle connexion HTTP.

Cela empêche une vulnérabilité de sécurité connue sous le nom de SSL-stripping.

Le décapage SSL est une attaque de rétrogradation introduite par Moxie Marlinspike dans son discours fédéral BlackHat de 2009  Nouvelles astuces pour vaincre SSL dans la pratique .

Une attaque de rétrogradation est une forme d'attaque cryptographique sur un système informatique ou, dans ce cas, un protocole de communication qui entraîne l'abandon de sa connexion chiffrée (HTTPS) au profit d'une ancienne connexion non chiffrée (HTTP) qui est généralement fournie pour la rétrocompatibilité. avec des systèmes plus anciens.

La suppression SSL est mise en œuvre dans le cadre d'une attaque de l'homme du milieu où le trafic Web est intercepté et redirigé de la version HTTPS sécurisée du site Web vers une version HTTP non chiffrée.

La principale raison pour laquelle cette attaque continue de réussir est que de nombreux sites Web n'utilisent toujours pas de certificats TLS / SSL. Il est donc impossible de savoir (sans connaissance préalable) si l'absence de HTTPS d'un site Web est due à une attaque de suppression SSL ou parce qu'il n'a pas de certificat TLS.

De plus, il n'y a pas d'alertes pour alerter l'utilisateur pendant le processus de rétrogradation, ce qui rend l'attaque difficile à détecter même pour l'utilisateur le plus vigilant.

Avec la création d'un outil par Marlinspike pour automatiser entièrement ce type d'attaque, cela pose un vrai risque de cybersécurité.

Détournement de session - Détournement de session

Le détournement de session ou le détournement de cookies est une autre vulnérabilité activée par l'insécurité des clics.

Le détournement de session exploite une session informatique valide pour obtenir un accès non autorisé à des informations ou à des services.

Ceci est particulièrement pertinent pour les développeurs Web car les cookies sont utilisés pour maintenir une session sur de nombreux sites Web.

Si un site Web ne marque pas ses cookies comme sûrs, indiquant aux agents utilisateurs d'envoyer des cookies uniquement via HTTPS, ils peuvent facilement être volés par un attaquant. Parce que les cookies non protégés sont renvoyés à l'hôte quelle que soit la sécurité du transport, les laissant ouverts aux attaques de l'homme du milieu.

Une fois qu'un attaquant a accès aux cookies, il peut alors se faire passer pour l'utilisateur sur un site Web légitime.

Comment fonctionne le HSTS ?

HSTS permet aux serveurs Web de déclarer que toute interaction par des navigateurs Web et d'autres agents utilisateurs doit être effectuée via des connexions HTTPS et non des connexions HTTP non sécurisées.

Un serveur peut mettre en œuvre une politique HSTS en fournissant un en-tête de réponse via une connexion HTTPS (les en-têtes HSTS envoyés via les en-têtes de réponse HTTP sont ignorés). L'en-tête HSTS est nommé Strict-Transport-Sécurité et spécifie également une période de temps pendant laquelle l'interpréteur doit accéder au service uniquement via des requêtes HTTPS. 

Cela signifie que la première fois que vous accédez à un site via HTTPS, il renvoie l'en-tête Strict-Transport-Security, le navigateur enregistre ces informations, de sorte que les futures tentatives de chargement du site via HTTP utilisent automatiquement HTTPS.

Après l'expiration du délai d'expiration spécifié par l'en-tête Strict-Transport-Security, la prochaine tentative de chargement du site via HTTP se déroulera normalement au lieu d'utiliser automatiquement HTTPS.

Cependant, chaque fois que l'en-tête Strict-Transport-Security est remis à l'agent utilisateur, il met à jour le délai d'expiration de ce site, afin que les sites puissent mettre à jour ces informations et empêcher l'expiration du délai.

S'il est nécessaire de désactiver HSTS, les serveurs Web peuvent définir l'âge maximum sur 0 (sur une connexion HTTPS) pour expirer immédiatement l'en-tête HSTS, permettant l'accès via des requêtes HTTP.

Par exemple, un serveur peut envoyer un en-tête demandant aux futures demandes pour l'année prochaine d'utiliser HTTPS uniquement via Strict-Transport-Security : max-age = 31536000

Lorsqu'une application Web envoie une politique HSTS aux agents utilisateurs, les agents utilisateurs conformes se comportent comme suit :

  • Tous les liens non sécurisés sont automatiquement transformés en liens sécurisés (par exemple, http://example.com/ sera remplacé par https://example.com avant d'accéder au serveur)
  • Si une connexion sécurisée ne peut pas être garantie (par exemple, le serveur ne dispose pas d'un certificat valide), l'agent utilisateur mettra fin à la connexion et ne permettra pas à l'utilisateur d'accéder au site Web.

La chose la plus importante à comprendre est qu'une politique HSTS empêche l'insécurité des clics en ne permettant pas à l'utilisateur final d'utiliser la connexion non sécurisée.

Quel est un exemple de situation impliquant le HSTS ?

Imaginez que votre employé utilise un point d'accès Wi-Fi gratuit dans un café et commence à surfer sur le Web, visitant le système de paie de votre organisation.

Malheureusement, le point d'accès qu'ils utilisent est en fait l'ordinateur portable d'un attaquant et ils interceptent la requête HTTP d'origine et redirigent votre employé vers un clone de votre système de paie au lieu du vrai, exposant les informations personnellement identifiables (PII) de vos employés. .

Si votre système de paie utilise HSTS et que votre employé l'a visité une fois en utilisant HTTPS, son navigateur saura qu'il n'utilise que HTTPS, empêchant ce type d'attaque de type "man-in-the-middle".

Quelles sont les limites du HSTS ?

Une limitation fondamentale de l'utilisation de HSTS est qu'un utilisateur qui ne peut pas se connecter via HTTPS ne pourra pas utiliser le site.

De plus, étant donné que la politique HSTS est communiquée dans un en-tête de réponse, l'agent utilisateur doit d'abord visiter le site Web pour savoir qu'il utilise HSTS.

Cela signifie que la demande initiale reste non sécurisée contre les attaques actives si elle utilise un protocole non sécurisé tel que le HTTP simple ou si l'URI de la demande initiale a été obtenue via un canal non sécurisé.

Cela s'appliquera également à la première demande après la période d'activité spécifiée dans le max-age HSTS (les sites fixent généralement une période de plusieurs jours ou mois en fonction de l'activité et du comportement de l'utilisateur).

Le HSTS est largement pris en charge par les navigateurs, notamment Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera et Safari, pour remédier à cette limitation en préchargeant les politiques HSTS à partir de la liste de préchargement HSTS. La liste HSTS contient des sites Web bien connus qui prennent en charge HSTS et sont distribués avec le navigateur, utilisez donc HTTPS pour la demande initiale des sites Web répertoriés. 

Étant donné que cette approche ne peut jamais s'étendre à l'ensemble du Web, il y a eu des discussions pour pouvoir déclarer HSTS dans les enregistrements DNS et y accéder dans passage sûr  DNSSEC , ce qui pourrait garantir la validité.

De plus, HSTS est inefficace contre les domaines de typosquattage, les attaques basées sur DNS et les attaques de l'homme du milieu qui acheminent le trafic à partir d'un domaine artificiel qui ne figure pas sur la liste de prélecture HSTS.

Et puisque HSTS s'appuie sur TLS lui-même, il s'appuie également sur la sécurité de TLS.

Lisez RFC 6797 pour une discussion plus approfondie des considérations générales de sécurité HSTS.

Quelles sont les meilleures pratiques pour déployer le HSTS ?

Si votre site est lié au HTTPS et que vous souhaitez précharger le HSTS, vous devez :

  • Fournir un certificat valide
  • Redirigez HTTP vers HTTPS sur le même hôte si vous écoutez sur le port 80
  • Servir tous les sous-domaines via HTTPS
  • Vous devez prendre en charge HTTPS pour le sous-domaine www si un enregistrement DNS existe pour ce sous-domaine
  • Vous avez besoin d'un en-tête HSTS dans le domaine de base pour les requêtes HTTPS :
  • L'âge maximum doit être d'au moins 31536000 secondes (1 an) doit être d'au moins
  • La directive includeSubDomains doit être spécifiée
  • La directive de préchargement doit être spécifiée
  • Si vous servez une redirection supplémentaire à partir de votre site HTTPS, cette redirection doit toujours avoir l'en-tête HSTS (plutôt que la page Web vers laquelle elle redirige)

Nous vous recommandons de commencer par les étapes suivantes :

  • Passez en revue tous les sous-domaines et sous-domaines imbriqués sur votre site et assurez-vous qu'ils fonctionnent sur HTTPS.
  • Activez HSTS pour toutes les réponses HTTPS et augmentez progressivement l'âge maximum. Au cours de chaque étape, recherchez les pages cassées, surveillez les statistiques de votre site et corrigez les problèmes qui surviennent, puis attendez l'âge maximum de l'étape avant de continuer. Vous pouvez utiliser les valeurs d'en-tête suivantes :
  • 5 minutes - Sécurité stricte des transports : max-age = 300 ; inclure les sous-domaines
  • 1 semaine - Sécurité stricte des transports : age-max = 604800 ; inclure les sous-domaines
  • 1 mois - Strict-Transport-Security : max-age = 2592000 ; inclure les sous-domaines
  • Une fois que vous êtes sûr qu'il n'y a pas de problème, augmentez l'âge maximum à 2 ans et soumettez votre site à la liste de préchargement HSTS avec la directive de préchargement :
  • 2 ans - Sécurité stricte des transports : age-max = 63072000 ; inclure les sous-domaines ; précharge
  • Vous pouvez ajouter votre site Web à la liste de préchargement HSTS via https://hstspreload.org/.

C'est ce que les projets Chromium veulent voir dans une soumission de préchargement.

Quelle est l'histoire de HSTS?

La spécification HSTS (RFC 6797) est basée sur les travaux originaux de Collin Jackson et Adam Barth dans un article intitulé  ForcedHTTPS : protection des sites Web hautement sécurisés contre les attaques réseau  , publié en 2008.

Le 18 septembre 2009, PayPal, Jackon et Barth ont publié une version mise à jour des grandes lignes du protocole dans le document original,  disponible ici .

Cela a conduit à la dernière "version communautaire" de la spécification "STS" alors nommée publiée le 18 décembre 2009, avec des révisions basées sur les commentaires de la communauté.

Enfin, le 19 novembre 2012, la spécification HSTS (RFC 6797) a été publiée après avoir été approuvée le 2 octobre 2012 par l'Internet Engineering Steering Group (IESG), une instance composée du président  de l'Internet Engineering Task Force (IETF) et des directeurs de zone.

Quels navigateurs prennent en charge HSTS ?

  • Chrome et Google Chrome à partir de la version 4.0.211.0
  • Firefox à partir de la version 4 ; avec Firefox 17, Mozilla intègre une liste de sites Web prenant en charge le HSTS
  • Opéra à partir de la version 12
  • Safari depuis OS X Mavericks version 10.9
  • Internet Explorer 11 sur Windows 8.1 et Windows 7 lorsque KB 3058515 est installé
  • Microsoft Edge et Internet Explorer 11 sur Windows 10
  • Navigateur BlackBerry 10 et WebView de BlackBerry OS 10.3.3

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modèle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

haut