14. Security Considerations (Considérations de Sécurité)
Cette spécification concerne l'expression, la communication et l'application de la politique HSTS. Le modèle de menace global de la politique HSTS, y compris les menaces traitées et non traitées, est donné dans la section 2.3 ("Threat Model").
De plus, les sections suivantes discutent des implications opérationnelles de la politique HSTS, fournissent la justification des fonctionnalités, discutent de l'abus potentiel de la politique HSTS, et mettent en évidence certaines vulnérabilités connues dans l'architecture de la politique HSTS.
14.1. Underlying Secure Transport Considerations (Considérations sur le Transport Sécurisé Sous-Jacent)
Cette spécification est conçue pour être indépendante du transport sécurisé sous-jacent à HTTP. Cependant, l'analyse des menaces et les exigences dans la section 2 ("Overview") supposent en fait TLS ou SSL comme transport sécurisé sous-jacent. Par conséquent, l'utilisation de HSTS dans des environnements où HTTP s'exécute sur d'autres protocoles de transport sécurisé nécessitera l'évaluation du modèle de sécurité de ce protocole de transport sécurisé et des détails spécifiques de la façon dont HTTP est superposé dessus, afin d'évaluer les propriétés de sécurité ultérieures de HSTS dans cet environnement.
14.2. Non-Conformant User Agent Implications (Implications des Agents Utilisateurs Non Conformes)
Les agents utilisateurs non conformes ignorent le champ d'en-tête Strict-Transport-Security; par conséquent, les agents utilisateurs non conformes ne peuvent pas résoudre les menaces décrites dans la section 2.3.1 ("Threats Addressed").
Cela signifie que les applications Web et leurs utilisateurs utilisant des UA non conformes seront vulnérables aux deux situations suivantes :
Attaques de Réseau Passives (dues à des erreurs de développement et de déploiement de sites Web)
Par exemple, si l'application Web contient des références non sécurisées (par exemple, "http") au serveur d'application Web, et si ses cookies ne sont pas tous marqués comme "Secure", alors ses cookies seront vulnérables au reniflage de réseau passif et pourraient entraîner un abus des informations d'identification de l'utilisateur.
Attaques de Réseau Actives (Active Network Attacks)
Par exemple, si un attaquant peut placer un "homme du milieu", les tentatives de connexion de transport sécurisé peuvent avertir l'utilisateur, mais en l'absence d'application de la politique HSTS, la pratique courante actuelle consiste à permettre à l'utilisateur de "cliquer" et de continuer. Cela rend les utilisateurs et l'application Web vulnérables aux abus par de tels attaquants.
14.3. Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport (Ramifications de l'Établissement de la Politique HSTS Uniquement sur Transport Sécurisé Sans Erreur)
Le modèle de traitement de l'agent utilisateur défini dans la section 8 ("User Agent Processing Model") stipule qu'un hôte n'est initialement noté comme hôte HSTS connu, ou que les informations mises en cache pour un hôte HSTS connu sont mises à jour, que si le UA reçoit le champ d'en-tête STS via une connexion de transport sécurisé sans erreur ou avertissement du transport sécurisé sous-jacent.
La justification derrière cela est que si un "homme du milieu" (MITM) est présent -- qu'il s'agisse d'un proxy légitimement déployé ou d'une entité illégitime -- il pourrait causer divers méfaits; par exemple :
Noter un hôte comme hôte HSTS connu de manière non autorisée
Si l'hôte ne peut pas offrir uniformément ses services via un transport sécurisé, cela pourrait entraîner une situation de déni de service (voir également section 14.5 ("Denial of Service")).
Réinitialiser la durée de vie de l'hôte en tant qu'hôte HSTS connu
En manipulant la valeur du paramètre de champ d'en-tête max-age retournée au UA. Si max-age est retourné comme zéro, cela ferait que le UA ne traite plus l'hôte comme un hôte HSTS connu, entraînant des connexions non sécurisées à l'hôte, ou éventuellement un déni de service si l'hôte offre uniquement des services via un transport sécurisé.
14.4. The Need for includeSubDomains (Le Besoin d'includeSubDomains)
Sans la directive includeSubDomains, les applications Web ne peuvent pas protéger adéquatement les soi-disant "cookies de domaine" (même lorsque ces cookies ont le drapeau "Secure" défini, et sont donc livrés uniquement sur des canaux sécurisés). Ce sont des cookies que l'application Web s'attend à ce que le UA retourne à n'importe quel et tous les sous-domaines de l'application Web.
14.5. Denial of Service (Déni de Service)
HSTS peut introduire intrinsèquement des vulnérabilités de déni de service.
14.6. Bootstrap MITM Vulnerability (Vulnérabilité de Bootstrap MITM)
Si un UA n'a pas encore interagi avec un hôte HSTS et qu'il n'est donc pas noté comme hôte HSTS connu, la première interaction est vulnérable aux attaques de l'homme du milieu.
14.7. Policy Deletion (Suppression de Politique)
Si le UA fournit un mécanisme pour supprimer la politique HSTS, un tel mécanisme doit être protégé contre l'exploitation par des attaquants.
14.8. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack (Attaque de Phishing de Certificat CA Racine Faux plus Empoisonnement de Cache DNS)
Un attaquant pourrait combiner un faux certificat CA racine avec un empoisonnement de cache DNS pour exécuter une attaque.
14.9. Creative Manipulation of HSTS Policy (Manipulation Créative de la Politique HSTS)
Si un attaquant peut manipuler le trafic réseau, il pourrait tenter d'abuser de la politique HSTS.
14.10. Internationalized Domain Names (Noms de Domaine Internationalisés)
L'utilisation de noms de domaine internationalisés (IDN) introduit des considérations de sécurité spécifiques. Les UA doivent (MUST) effectuer une validation IDNA appropriée avant de traiter les politiques HSTS.
Pour plus de détails, veuillez vous référer à la spécification complète du RFC 6797.