9. Considérations de sécurité
Cette section est destinée à informer les développeurs, les fournisseurs d'information et les utilisateurs des considérations de sécurité connues concernant la syntaxe, l'analyse et le routage des messages HTTP. Les considérations de sécurité relatives à la sémantique et aux charges utiles de HTTP sont traitées dans [RFC7231].
9.1. Établissement de l'autorité
HTTP repose sur la notion de réponse faisant autorité : une réponse qui a été déterminée par l'autorité identifiée dans l'URI cible (ou sous sa direction) comme la réponse la plus appropriée à cette requête, compte tenu de l'état de la ressource cible au moment de la création du message de réponse. Fournir une réponse provenant d'une source non faisant autorité, telle qu'un cache partagé, est souvent utile pour améliorer les performances et la disponibilité, mais seulement dans la mesure où la source peut être digne de confiance ou où la réponse non fiable peut être utilisée sans danger.
Malheureusement, établir l'autorité peut être difficile. Par exemple, l'hameçonnage est une attaque contre la perception que l'utilisateur a de l'autorité, cette perception pouvant être trompée en présentant une image de marque similaire dans l'hypertexte, éventuellement aidée par un userinfo qui masque le composant authority (voir la Section 2.7.1). Les agents utilisateurs peuvent réduire l'impact des attaques d'hameçonnage en permettant aux utilisateurs d'examiner facilement un URI cible avant d'agir, en distinguant clairement (ou en rejetant) le userinfo lorsqu'il est présent, et en n'envoyant pas d'identifiants stockés ni de cookies lorsque le document référent provient d'une source inconnue ou non fiable.
Lorsqu'un nom enregistré est utilisé dans le composant authority, le schéma d'URI « http » (Section 2.7.1) s'appuie sur le service local de résolution de noms de l'utilisateur pour déterminer où il peut trouver des réponses faisant autorité. Cela signifie que toute attaque contre la table des hôtes réseau de l'utilisateur, contre des noms mis en cache ou contre les bibliothèques de résolution de noms devient une voie d'attaque contre l'établissement de l'autorité. De même, le choix par l'utilisateur du serveur pour le service de noms de domaine (DNS), et la hiérarchie des serveurs auprès desquels il obtient les résultats de résolution, peuvent avoir une incidence sur l'authenticité des correspondances d'adresses ; les DNS Security Extensions (DNSSEC, [RFC4033]) sont un moyen d'améliorer l'authenticité.
En outre, une fois une adresse IP obtenue, l'établissement de l'autorité pour un URI « http » est vulnérable aux attaques contre le routage du protocole Internet.
Le schéma « https » (Section 2.7.2) vise à prévenir (ou du moins à révéler) un grand nombre de ces attaques potentielles contre l'établissement de l'autorité, à condition que la connexion TLS négociée soit sécurisée et que le client vérifie correctement que l'identité du serveur avec lequel il communique correspond au composant authority de l'URI cible (voir [RFC2818]). Une mise en œuvre correcte d'une telle vérification peut être difficile (voir [Georgiev]).
9.2. Risques liés aux intermédiaires
De par leur nature même, les intermédiaires HTTP sont des hommes du milieu et représentent donc une occasion d'attaques de l'homme du milieu. La compromission des systèmes sur lesquels s'exécutent les intermédiaires peut entraîner de graves problèmes de sécurité et de vie privée. Les intermédiaires peuvent avoir accès à des informations liées à la sécurité, à des informations personnelles sur des utilisateurs et des organisations, et à des informations exclusives appartenant à des utilisateurs et à des fournisseurs de contenu. Un intermédiaire compromis, ou un intermédiaire implémenté ou configuré sans égard aux considérations de sécurité et de vie privée, peut être utilisé pour commettre un large éventail d'attaques potentielles.
Les intermédiaires qui contiennent un cache partagé sont particulièrement vulnérables aux attaques par empoisonnement de cache, comme décrit à la Section 8 de [RFC7234].
Les implémenteurs doivent tenir compte des implications pour la vie privée et la sécurité de leurs choix de conception et de codage, ainsi que des options de configuration qu'ils offrent aux opérateurs (en particulier la configuration par défaut).
Les utilisateurs doivent être conscients que les intermédiaires ne sont pas plus dignes de confiance que les personnes qui les exploitent ; HTTP lui-même ne peut pas résoudre ce problème.
9.3. Attaques par la longueur des éléments de protocole
Comme HTTP utilise principalement des champs textuels délimités par caractères, les analyseurs sont souvent vulnérables à des attaques fondées sur l'envoi de flux de données très longs (ou très lents), en particulier lorsqu'une implémentation s'attend à un élément de protocole sans longueur prédéfinie.
Pour favoriser l'interopérabilité, des recommandations précises sont formulées quant aux limites de taille minimales de la ligne de requête (Section 3.1.1) et des champs d'en-tête (Section 3.2). Ce sont des recommandations minimales, choisies pour être supportables même par des implémentations disposant de ressources limitées ; on s'attend à ce que la plupart des implémentations retiennent des limites sensiblement plus élevées.
Un serveur peut rejeter un message dont la cible de requête est trop longue (Section 6.5.12 de [RFC7231]) ou dont la charge utile de requête est trop volumineuse (Section 6.5.11 de [RFC7231]). Des codes d'état supplémentaires liés aux limites de capacité ont été définis par des extensions de HTTP [RFC6585].
Les destinataires devraient limiter soigneusement l'ampleur du traitement qu'ils appliquent aux autres éléments de protocole, notamment (mais sans s'y limiter) les méthodes de requête, les phrases d'état de réponse, les noms de champs d'en-tête, les valeurs numériques et les chunks de corps. Ne pas limiter un tel traitement peut entraîner des débordements de tampon, des débordements arithmétiques, ou une vulnérabilité accrue aux attaques par déni de service.
9.4. Division de réponse
La division de réponse (aussi appelée injection CRLF) est une technique courante, utilisée dans diverses attaques contre l'usage du Web, qui exploite la nature fondée sur les lignes du cadrage des messages HTTP et l'association ordonnée des requêtes aux réponses sur les connexions persistantes [Klein]. Cette technique peut être particulièrement dommageable lorsque les requêtes passent par un cache partagé.
La division de réponse exploite une vulnérabilité des serveurs (généralement au sein d'un serveur applicatif) où un attaquant peut envoyer des données encodées dans un paramètre quelconque de la requête, qui sont ensuite décodées et reproduites dans l'un des champs d'en-tête de la réponse. Si les données décodées sont forgées de manière à donner l'impression que la réponse s'est terminée et qu'une réponse suivante a commencé, la réponse a été divisée et le contenu de l'apparente seconde réponse est contrôlé par l'attaquant. L'attaquant peut alors émettre n'importe quelle autre requête sur la même connexion persistante et amener les destinataires (y compris les intermédiaires) à croire que la seconde moitié de la division est une réponse faisant autorité à la seconde requête.
Par exemple, un paramètre de la cible de requête peut être lu par un serveur applicatif et réutilisé dans une redirection, ce qui conduit le même paramètre à être reproduit dans le champ d'en-tête Location de la réponse. Si le paramètre est décodé par l'application et mal encodé lors de son insertion dans le champ de réponse, l'attaquant peut envoyer des octets CRLF encodés et d'autres contenus qui feront ressembler la réponse unique de l'application à deux réponses ou plus.
Une défense courante contre la division de réponse consiste à filtrer les requêtes à la recherche de données ressemblant à des CR et LF encodés (par exemple « %0D » et « %0A »). Cependant, cela suppose que le serveur applicatif n'effectue qu'un décodage d'URI, et non des transformations de données plus obscures comme le transcodage de jeux de caractères, la traduction d'entités XML, le décodage base64, le reformatage sprintf, etc. Une atténuation plus efficace consiste à empêcher tout composant autre que les bibliothèques de protocole centrales du serveur d'envoyer un CR ou un LF dans la section d'en-tête, ce qui implique de restreindre la sortie des champs d'en-tête à des API qui filtrent les octets indésirables et d'interdire aux serveurs applicatifs d'écrire directement dans le flux protocolaire.
9.5. Contrebande de requêtes
La contrebande de requêtes ([Linhart]) est une technique qui exploite les différences d'analyse du protocole entre divers destinataires pour dissimuler des requêtes supplémentaires (qui seraient autrement bloquées ou désactivées par une politique) à l'intérieur d'une requête apparemment inoffensive. Comme la division de réponse, la contrebande de requêtes peut mener à diverses attaques contre l'usage de HTTP.
Cette spécification a introduit de nouvelles exigences sur l'analyse des requêtes, en particulier en ce qui concerne le cadrage des messages à la Section 3.3.3, afin de réduire l'efficacité de la contrebande de requêtes.
9.6. Intégrité du message
HTTP ne définit pas de mécanisme particulier pour garantir l'intégrité des messages, s'appuyant à la place sur la capacité de détection d'erreurs des protocoles de transport sous-jacents et sur l'usage d'un cadrage délimité par une longueur ou par des chunks pour détecter l'achèvement. Des mécanismes d'intégrité supplémentaires, tels que des fonctions de hachage ou des signatures numériques appliquées au contenu, peuvent être ajoutés sélectivement aux messages au moyen de champs d'en-tête de métadonnées extensibles. Historiquement, l'absence d'un mécanisme d'intégrité unique se justifiait par la nature informelle de la plupart des communications HTTP. Cependant, la prévalence de HTTP comme mécanisme d'accès à l'information a conduit à son utilisation croissante dans des environnements où la vérification de l'intégrité des messages est cruciale.
Les agents utilisateurs sont encouragés à implémenter des moyens configurables de détecter et de signaler les défaillances d'intégrité des messages, afin que ces moyens puissent être activés dans les environnements où l'intégrité est nécessaire. Par exemple, un navigateur utilisé pour consulter des antécédents médicaux ou des informations sur les interactions médicamenteuses doit indiquer à l'utilisateur lorsque ces informations sont détectées par le protocole comme incomplètes, expirées ou corrompues pendant le transfert. De tels mécanismes peuvent être activés sélectivement via des extensions d'agent utilisateur ou la présence de métadonnées d'intégrité de message dans une réponse. Au minimum, les agents utilisateurs devraient fournir une indication quelconque permettant à un utilisateur de distinguer un message de réponse complet d'un message incomplet (Section 3.4) lorsque cette vérification est souhaitée.
9.7. Confidentialité du message
HTTP s'appuie sur les protocoles de transport sous-jacents pour assurer la confidentialité des messages lorsque celle-ci est souhaitée. HTTP a été spécifiquement conçu pour être indépendant du protocole de transport, de sorte qu'il peut être utilisé sur de nombreuses formes différentes de connexion chiffrée, le choix de ces transports étant identifié par le choix du schéma d'URI ou dans la configuration de l'agent utilisateur.
Le schéma « https » peut être utilisé pour identifier des ressources qui exigent une connexion confidentielle, comme décrit à la Section 2.7.2.
9.8. Confidentialité des informations des journaux serveur
Un serveur est en mesure d'enregistrer dans le temps des données personnelles sur les requêtes d'un utilisateur, ce qui peut révéler ses habitudes de lecture ou ses sujets d'intérêt. En particulier, les informations de journal recueillies au niveau d'un intermédiaire contiennent souvent un historique des interactions d'agents utilisateurs, à travers une multitude de sites, qui peut être rattaché à des utilisateurs individuels.
Les informations de journal HTTP sont de nature confidentielle ; leur traitement est souvent encadré par des lois et des règlements. Les informations de journal doivent être stockées de manière sécurisée et des lignes directrices appropriées doivent être suivies pour leur analyse. L'anonymisation des informations personnelles au sein des entrées individuelles aide, mais elle n'est généralement pas suffisante pour empêcher la réidentification de traces de journal réelles à partir d'une corrélation avec d'autres caractéristiques d'accès. À ce titre, les traces d'accès rattachées à un client particulier ne peuvent pas être publiées sans danger, même si la clé est pseudonyme.
Pour minimiser le risque de vol ou de publication accidentelle, les informations de journal devraient être purgées des informations personnelles identifiables, y compris les identifiants d'utilisateur, les adresses IP et les paramètres de requête fournis par l'utilisateur, dès que ces informations ne sont plus nécessaires pour répondre aux besoins opérationnels de sécurité, d'audit ou de lutte contre la fraude.