17. Security Considerations (Considérations de sécurité)

Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des problèmes de sécurité connus concernant la sémantique HTTP et son utilisation pour le transfert d'informations sur Internet. Les considérations liées à la mise en cache sont discutées dans la Section 7 de [CACHING], et les considérations liées à la syntaxe et à l'analyse des messages HTTP/1.1 sont discutées dans la Section 11 de [HTTP/1.1].

La liste des considérations ci-dessous n'est pas exhaustive. La plupart des problèmes de sécurité liés à la sémantique HTTP concernent la sécurisation des applications côté serveur (code derrière l'interface HTTP), la sécurisation du traitement par l'agent utilisateur du contenu reçu via HTTP, ou l'utilisation sécurisée d'Internet en général, plutôt que la sécurité du protocole lui-même. Les considérations de sécurité pour les URI, qui sont fondamentales pour les opérations HTTP, sont discutées dans la Section 7 de [URI]. Diverses organisations maintiennent des informations thématiques et des liens vers la recherche actuelle sur la sécurité des applications Web (par exemple, [OWASP]).

17.1. Establishing Authority (Établissement de l'autorité)

HTTP repose sur la notion de "réponse autoritaire": une réponse qui a été déterminée par (ou sous la direction de) le serveur d'origine identifié dans l'URI cible comme étant la réponse la plus appropriée pour cette requête compte tenu de l'état de la ressource cible au moment de l'origine du message de réponse.

Lorsqu'un nom enregistré est utilisé dans le composant d'autorité, le schéma URI "http" (Section 4.2.1) s'appuie sur le service de résolution de noms local de l'utilisateur pour déterminer où il peut trouver des réponses autoritaires. Cela signifie que toute attaque sur la table d'hôtes réseau de l'utilisateur, les noms en cache ou les bibliothèques de résolution de noms devient un vecteur d'attaque sur l'établissement de l'autorité pour les URI "http". De même, le choix de l'utilisateur du serveur pour le service de noms de domaine (DNS), et la hiérarchie de serveurs à partir de laquelle il obtient les résultats de résolution, pourrait avoir un impact sur l'authenticité des mappages d'adresses; les extensions de sécurité DNS (DNSSEC, [RFC4033]) sont un moyen d'améliorer l'authenticité, tout comme les divers mécanismes pour effectuer des requêtes DNS sur des protocoles de transfert plus sécurisés.

De plus, après l'obtention d'une adresse IP, l'établissement de l'autorité pour un URI "http" est vulnérable aux attaques sur le routage du protocole Internet.

Le schéma "https" (Section 4.2.2) vise à prévenir (ou du moins révéler) de nombreuses attaques potentielles sur l'établissement de l'autorité, à condition que la connexion négociée soit sécurisée et que le client vérifie correctement que l'identité du serveur communicant correspond au composant d'autorité de l'URI cible (Section 4.3.4). Implémenter correctement une telle vérification peut être difficile (voir [Georgiev]).

L'autorité pour un serveur d'origine donné peut être déléguée par des extensions de protocole; par exemple, [ALTSVC]. De même, l'ensemble des serveurs pour lesquels une connexion est considérée comme autoritaire peut être modifié avec une extension de protocole comme [RFC8336].

Fournir une réponse à partir d'une source non autoritaire, telle qu'un cache de proxy partagé, est souvent utile pour améliorer les performances et la disponibilité, mais seulement dans la mesure où la source peut être approuvée ou la réponse non approuvée peut être utilisée en toute sécurité.

Malheureusement, communiquer l'autorité aux utilisateurs peut être difficile. Par exemple, le "phishing" est une attaque sur la perception de l'autorité par l'utilisateur, où cette perception peut être induite en erreur en présentant une marque similaire dans l'hypertexte, éventuellement aidée par userinfo obscurcissant le composant d'autorité (voir Section 4.2.1). Les agents utilisateurs peuvent réduire l'impact des attaques de phishing en permettant aux utilisateurs d'inspecter facilement un URI cible avant d'effectuer une action, en distinguant de manière proéminente (ou en rejetant) userinfo lorsqu'il est présent, et en n'envoyant pas les informations d'identification stockées et les cookies lorsque le document référent provient d'une source inconnue ou non approuvée.

17.2. Risks of Intermediaries (Risques des intermédiaires)

Les intermédiaires HTTP sont intrinsèquement situés pour des attaques sur le chemin. La compromission des systèmes sur lesquels les intermédiaires s'exécutent peut entraîner de graves problèmes de sécurité et de confidentialité. Les intermédiaires peuvent avoir accès à des informations liées à la sécurité, à des informations personnelles sur des utilisateurs individuels et des organisations, et à des informations propriétaires appartenant aux utilisateurs et aux fournisseurs de contenu. Un intermédiaire compromis, ou un intermédiaire implémenté ou configuré sans tenir compte des considérations de sécurité et de confidentialité, pourrait être utilisé dans la commission d'un large éventail d'attaques potentielles.

Les intermédiaires qui contiennent un cache partagé sont particulièrement vulnérables aux attaques d'empoisonnement du cache, comme décrit dans la Section 7 de [CACHING].

Les implémenteurs doivent tenir compte des implications en matière de confidentialité et de sécurité de leurs décisions de conception et de codage, et des options de configuration qu'ils offrent aux opérateurs (en particulier la configuration par défaut).

Les intermédiaires ne sont pas plus dignes de confiance que les personnes et les politiques sous lesquelles ils opèrent; HTTP ne peut pas résoudre ce problème.

17.3. Attacks Based on File and Path Names (Attaques basées sur les noms de fichiers et de chemins)

Les serveurs d'origine utilisent fréquemment leur système de fichiers local pour gérer le mappage de l'URI cible aux représentations de ressources. La plupart des systèmes de fichiers ne sont pas conçus pour se protéger contre les noms de fichiers ou de chemins malveillants. Par conséquent, un serveur d'origine doit éviter d'accéder aux noms qui ont une signification spéciale pour le système lors du mappage de la ressource cible vers des fichiers, des dossiers ou des répertoires.

Par exemple, UNIX, Microsoft Windows et d'autres systèmes d'exploitation utilisent ".." comme composant de chemin pour indiquer un niveau de répertoire au-dessus du niveau actuel, et ils utilisent des chemins ou des noms de fichiers spécialement nommés pour envoyer des données aux périphériques système. Des conventions de nommage similaires peuvent exister dans d'autres types de systèmes de stockage. De même, les systèmes de stockage locaux ont une tendance ennuyeuse à préférer la convivialité à la sécurité lors du traitement des caractères invalides ou inattendus, de la recomposition des caractères décomposés et de la normalisation de la casse des noms insensibles à la casse.

Les attaques basées sur de tels noms spéciaux ont tendance à se concentrer soit sur le déni de service (par exemple, demander au serveur de lire à partir d'un port COM) soit sur la divulgation de fichiers de configuration et de source qui ne sont pas destinés à être servis.

17.4. Attacks Based on Command, Code, or Query Injection (Attaques basées sur l'injection de commandes, de code ou de requêtes)

Les serveurs d'origine utilisent souvent des paramètres dans l'URI comme moyen d'identifier les services système, de sélectionner des entrées de base de données ou de choisir une source de données. Cependant, les données reçues dans une requête ne peuvent pas être approuvées. Un attaquant pourrait construire n'importe quel élément de données de requête (méthode, URI cible, champs d'en-tête ou contenu) pour contenir des données qui pourraient être mal interprétées comme une commande, un code ou une requête lorsqu'elles sont transmises via une invocation de commande, un interpréteur de langage ou une interface de base de données.

Par exemple, l'injection SQL est une attaque courante dans laquelle un langage de requête supplémentaire est inséré dans une partie de l'URI cible ou des champs d'en-tête (par exemple, Host, Referer, etc.). Si les données reçues sont utilisées directement dans une instruction SELECT, le langage de requête pourrait être interprété comme une commande de base de données au lieu d'une simple valeur de chaîne. Ce type de vulnérabilité d'implémentation est extrêmement courant, malgré le fait qu'il soit facile à prévenir.

En général, les implémentations de ressources devraient éviter l'utilisation de données de requête dans des contextes qui sont traités ou interprétés comme des instructions. Les paramètres devraient être comparés à des chaînes fixes et agir en fonction du résultat de cette comparaison, plutôt que d'être transmis via une interface qui n'est pas préparée pour des données non approuvées. Les données reçues qui ne sont pas basées sur des paramètres fixes devraient être soigneusement filtrées ou encodées pour éviter d'être mal interprétées.

Des considérations similaires s'appliquent aux données de requête lorsqu'elles sont stockées et traitées ultérieurement, par exemple dans les fichiers journaux, les outils de surveillance, ou lorsqu'elles sont incluses dans un format de données qui permet des scripts intégrés.

17.5. Attacks via Protocol Element Length (Attaques via la longueur des éléments de protocole)

Parce que HTTP utilise principalement des champs textuels délimités par des caractères, les analyseurs sont souvent vulnérables aux attaques basées sur l'envoi de flux de données très longs (ou très lents), en particulier lorsqu'une implémentation attend un élément de protocole sans longueur prédéfinie (Section 2.3).

Pour promouvoir l'interopérabilité, des recommandations spécifiques sont faites pour les limites de taille minimale sur les champs (Section 5.4). Ce sont des recommandations minimales, choisies pour être supportables même par des implémentations avec des ressources limitées; il est attendu que la plupart des implémentations choisiront des limites substantiellement plus élevées.

Un serveur peut rejeter un message qui a un URI cible trop long (Section 15.5.15) ou un contenu de requête trop volumineux (Section 15.5.14). Des codes d'état supplémentaires liés aux limites de capacité ont été définis par des extensions à HTTP [RFC6585].

Les destinataires devraient limiter soigneusement dans quelle mesure ils traitent d'autres éléments de protocole, y compris (mais sans s'y limiter) les méthodes de requête, les phrases d'état de réponse, les noms de champs, les valeurs numériques et les longueurs de morceaux. Le fait de ne pas limiter ce traitement peut entraîner l'exécution de code arbitraire en raison de débordements de tampon ou arithmétiques, et une vulnérabilité accrue aux attaques par déni de service.

17.6. Attacks Using Shared-Dictionary Compression (Attaques utilisant la compression à dictionnaire partagé)

Certaines attaques sur les protocoles chiffrés utilisent les différences de taille créées par la compression dynamique pour révéler des informations confidentielles; par exemple, [BREACH]. Ces attaques reposent sur la création d'une redondance entre le contenu contrôlé par l'attaquant et les informations confidentielles, de sorte qu'un algorithme de compression dynamique utilisant le même dictionnaire pour les deux contenus compressera plus efficacement lorsque le contenu contrôlé par l'attaquant correspond à des parties du contenu confidentiel.

Les messages HTTP peuvent être compressés de plusieurs façons, notamment en utilisant la compression TLS, les codages de contenu, les codages de transfert et d'autres mécanismes d'extension ou spécifiques à une version.

L'atténuation la plus efficace pour ce risque est de désactiver la compression sur les données sensibles, ou de séparer strictement les données sensibles des données contrôlées par l'attaquant afin qu'elles ne puissent pas partager le même dictionnaire de compression. Avec une conception soigneuse, un schéma de compression peut être conçu de manière à ne pas être considéré comme exploitable dans des cas d'utilisation limités, tels que HPACK ([HPACK]).

17.7. Disclosure of Personal Information (Divulgation d'informations personnelles)

Les clients ont souvent accès à de grandes quantités d'informations personnelles, y compris les informations fournies par l'utilisateur pour interagir avec les ressources (par exemple, le nom de l'utilisateur, l'emplacement, l'adresse e-mail, les mots de passe, les clés de chiffrement, etc.) et les informations sur l'activité de navigation de l'utilisateur au fil du temps (par exemple, l'historique, les signets, etc.). Les implémentations doivent empêcher la fuite involontaire d'informations personnelles.

17.8. Privacy of Server Log Information (Confidentialité des informations de journal du serveur)

Les serveurs sont en mesure de sauvegarder des données personnelles sur les requêtes d'un utilisateur au fil du temps, ce qui pourrait identifier leurs modèles de lecture ou leurs sujets d'intérêt. En particulier, les informations de journal collectées par les intermédiaires contiennent souvent un historique des interactions de l'agent utilisateur sur une multitude de sites, traçables jusqu'aux utilisateurs individuels.

Les informations de journal HTTP sont de nature confidentielle; leur traitement est souvent contraint par les lois et les réglementations. Les informations de journal doivent être stockées en toute sécurité et des directives appropriées doivent être suivies pour leur analyse. L'anonymisation des informations personnelles dans les entrées individuelles aide, mais n'est généralement pas suffisante pour empêcher les traces de journal réelles d'être ré-identifiées sur la base de corrélations avec d'autres caractéristiques d'accès. En tant que telles, les traces d'accès liées à un client spécifique ne sont pas sûres à publier 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 personnellement 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 soutenir les besoins opérationnels de sécurité, d'auditabilité ou de contrôle de fraude.

17.9. Disclosure of Sensitive Information in URIs (Divulgation d'informations sensibles dans les URI)

Les URI sont destinés à être partagés, pas sécurisés, même lorsqu'ils identifient des ressources sécurisées. Les URI sont souvent affichés sur des écrans, ajoutés aux modèles lors de l'impression d'une page et stockés dans diverses listes de signets non protégées. De nombreux serveurs, proxies et agents utilisateurs journalisent ou affichent l'URI cible dans des endroits qui pourraient être visibles par des tiers. Par conséquent, il est imprudent d'inclure des informations sensibles, personnellement identifiables ou à risque dans un URI.

Lorsqu'une application utilise des mécanismes côté client pour construire un URI cible à partir d'informations fournies par l'utilisateur, telles que les champs de requête d'un formulaire utilisant GET, des données potentiellement sensibles pourraient être fournies qui seraient inappropriées à inclure dans un URI. Dans ces cas, POST est souvent préféré, car il ne construit généralement pas d'URI; au lieu de cela, le POST d'un formulaire transmet les données potentiellement sensibles dans le contenu de la requête. Cependant, cela entrave la mise en cache et utilise une méthode non sûre pour ce qui serait autrement une requête sûre. Les solutions de contournement alternatives incluent la transformation des données fournies par l'utilisateur avant de construire l'URI ou le filtrage des données pour n'inclure que des valeurs communes qui ne sont pas sensibles. De même, la redirection des résultats d'une requête vers un URI différent (généré par le serveur) peut supprimer les données potentiellement sensibles des liens ultérieurs et fournir une réponse cacheable pour une réutilisation ultérieure.

Étant donné que le champ d'en-tête Referer indique au site cible le contexte qui a donné lieu à la requête, il a le potentiel de révéler des informations sur l'historique de navigation immédiat de l'utilisateur et toute information personnelle qui pourrait être trouvée dans l'URI de la ressource référente. Les limitations sur le champ d'en-tête Referer sont décrites dans la Section 10.1.3 pour aborder certaines de ses considérations de sécurité.

17.10. Application Handling of Field Names (Traitement par l'application des noms de champs)

Les serveurs utilisent souvent des interfaces de passerelle non HTTP et des frameworks pour traiter une requête reçue et générer le contenu d'une réponse. Pour des raisons historiques, de telles interfaces transmettent souvent les noms de champs reçus comme noms de variables externes, en utilisant un mappage de noms approprié pour les variables d'environnement.

Par exemple, le mappage des métavariables spécifiques au protocole de l'interface de passerelle commune (CGI) défini dans la Section 4.1.18 de [RFC3875] s'applique aux champs d'en-tête reçus qui ne correspondent pas à l'une des variables standard de CGI; ce mappage consiste à ajouter "HTTP_" devant chaque nom et à changer toutes les instances de trait d'union ("-") en trait de soulignement ("_"). De nombreux autres frameworks d'application ont hérité de ce même mappage afin de simplifier le déplacement d'applications d'une plateforme à une autre.

Dans CGI, un champ Content-Length reçu serait transmis en tant que métavariable "CONTENT_LENGTH" avec une valeur de chaîne correspondant à la valeur de champ reçue. En revanche, un champ d'en-tête "Content_Length" reçu serait transmis en tant que métavariable spécifique au protocole "HTTP_CONTENT_LENGTH", ce qui pourrait entraîner une certaine confusion si l'application lit par erreur la métavariable spécifique au protocole au lieu de celle par défaut. (Cette pratique historique est la raison pour laquelle la Section 16.3.2.1 déconseille la création de nouveaux noms de champs contenant un trait de soulignement.)

Malheureusement, le mappage de noms de champs vers des noms d'interface différents peut conduire à des vulnérabilités de sécurité si le mappage est incomplet ou ambigu. Par exemple, si un attaquant devait envoyer un champ nommé "Transfer_Encoding", une interface naïve pourrait le mapper au même nom de variable que le champ "Transfer-Encoding", entraînant une vulnérabilité potentielle de contrebande de requêtes (Section 11.2 de [HTTP/1.1]).

Pour atténuer les risques associés, il est conseillé aux implémentations qui effectuent de tels mappages de rendre le mappage non ambigu et complet pour la gamme complète d'octets potentiels reçus en tant que nom (y compris ceux qui sont découragés ou interdits par la grammaire HTTP). Par exemple, un champ avec un caractère de nom inhabituel pourrait entraîner le blocage de la requête, la suppression du champ spécifique ou la transmission du nom avec un préfixe différent pour le distinguer des autres champs.

17.11. Disclosure of Fragment after Redirects (Divulgation du fragment après les redirections)

Bien que les identifiants de fragment utilisés dans les références URI ne soient pas envoyés dans les requêtes, les implémenteurs doivent être conscients qu'ils seront visibles par l'agent utilisateur et toutes les extensions ou scripts s'exécutant en conséquence de la réponse. En particulier, lorsqu'une redirection se produit et que l'identifiant de fragment de la requête originale est hérité par la nouvelle référence dans Location (Section 10.2.2), cela peut avoir l'effet de divulguer le fragment d'un site à un autre site. Si le premier site utilise des informations personnelles dans les fragments, il devrait s'assurer que les redirections vers d'autres sites incluent un composant de fragment (éventuellement vide) afin de bloquer cet héritage.

17.12. Disclosure of Product Information (Divulgation d'informations sur les produits)

Les champs d'en-tête User-Agent (Section 10.1.5), Via (Section 7.6.3) et Server (Section 10.2.4) révèlent souvent des informations sur les systèmes logiciels de leurs expéditeurs respectifs. En théorie, cela facilite l'exploitation par un attaquant de trous de sécurité connus; en pratique, les attaquants ont tendance à essayer tous les trous potentiels quelles que soient les versions logicielles apparemment utilisées.

Les proxies qui servent de passerelle vers un pare-feu réseau devraient prendre des précautions spéciales concernant le transfert d'informations d'en-tête qui pourraient identifier les hôtes derrière le pare-feu. Le champ d'en-tête Via permet aux intermédiaires de remplacer les noms de machines sensibles par des pseudonymes.

17.13. Browser Fingerprinting (Empreinte digitale du navigateur)

L'empreinte digitale du navigateur est un ensemble de techniques pour identifier un agent utilisateur spécifique au fil du temps à travers son ensemble unique de caractéristiques. Ces caractéristiques peuvent inclure des informations liées à la façon dont il utilise le protocole de transport sous-jacent, les capacités des fonctionnalités et l'environnement de script, bien que ce qui soit particulièrement intéressant ici soit l'ensemble de caractéristiques uniques qui pourraient être communiquées via HTTP. L'empreinte digitale est considérée comme une préoccupation en matière de confidentialité car elle permet de suivre le comportement de l'agent utilisateur au fil du temps ([Bujlow]) sans les contrôles correspondants que l'utilisateur pourrait avoir sur d'autres formes de collecte de données (par exemple, les cookies). De nombreux agents utilisateurs à usage général (c'est-à-dire les navigateurs Web) ont pris des mesures pour réduire leur empreinte.

Il existe un certain nombre de champs d'en-tête de requête qui pourraient révéler aux serveurs des informations suffisamment uniques pour permettre l'empreinte digitale. Le champ d'en-tête From est le plus évident, bien qu'il soit attendu que From ne soit envoyé que lorsque l'utilisateur souhaite s'auto-identifier. De même, le champ d'en-tête Cookie est délibérément conçu pour permettre la ré-identification, de sorte que les préoccupations d'empreinte digitale ne s'appliquent qu'aux situations où les cookies sont désactivés ou limités par configuration.

Le champ d'en-tête User-Agent peut contenir suffisamment d'informations pour identifier de manière unique un appareil spécifique, généralement lorsqu'il est combiné avec d'autres caractéristiques, en particulier si l'agent utilisateur envoie des détails excessifs sur le système ou les extensions de l'utilisateur. Cependant, la source d'informations uniques que la plupart des utilisateurs pourraient ne pas attendre est la négociation proactive (Section 12.1), y compris les champs d'en-tête Accept, Accept-Charset, Accept-Encoding et Accept-Language.

En plus de la préoccupation d'empreinte digitale, l'utilisation détaillée du champ d'en-tête Accept-Language peut révéler des informations que l'utilisateur pourrait considérer comme étant de nature privée. Par exemple, la compréhension d'un ensemble donné de langues pourrait être fortement corrélée à l'appartenance à un groupe ethnique particulier. Une approche qui limite une telle perte de confidentialité serait que les agents utilisateurs omettent d'envoyer Accept-Language sauf pour les sites qui ont été explicitement autorisés, peut-être via une interaction après avoir détecté un champ d'en-tête Vary indiquant que la négociation de langue pourrait être utile.

Dans les environnements où des proxies sont utilisés pour améliorer la confidentialité, les agents utilisateurs devraient être conservateurs dans l'envoi de champs d'en-tête de négociation proactive. Les agents utilisateurs à usage général qui offrent un haut degré de configurabilité des champs d'en-tête devraient informer les utilisateurs de la perte de confidentialité qui pourrait résulter si trop de détails sont fournis. En tant que mesure de confidentialité extrême, les proxies pourraient filtrer les champs d'en-tête de négociation proactive dans les requêtes relayées.

17.14. Validator Retention (Rétention des validateurs)

Les validateurs définis par cette spécification ne sont pas destinés à assurer la validité d'une représentation, à protéger contre les modifications malveillantes ou à détecter les attaques sur le chemin. Au mieux, ils permettent des mises à jour de cache plus efficaces et des écritures concurrentes optimistes lorsque tous les participants se comportent bien. Au pire, les conditions échoueront et le client recevra une réponse qui n'est pas plus nuisible qu'un échange HTTP sans requêtes conditionnelles.

Une balise d'entité peut être abusée de manière à créer des risques de confidentialité. Par exemple, un site pourrait délibérément construire une balise d'entité sémantiquement invalide qui est unique à l'utilisateur ou à l'agent utilisateur, l'envoyer dans une réponse cacheable avec un temps de fraîcheur long, puis lire cette balise d'entité dans des requêtes conditionnelles ultérieures comme moyen de ré-identifier cet utilisateur ou cet agent utilisateur. Un tel identifiant deviendrait un identifiant persistant aussi longtemps que l'agent utilisateur conserve l'entrée de cache originale. Les agents utilisateurs qui mettent en cache des représentations devraient s'assurer que le cache est effacé ou remplacé chaque fois que l'utilisateur effectue des actions de maintien de la confidentialité, telles que l'effacement des cookies stockés ou le passage à un mode de navigation privée.

17.15. Denial-of-Service Attacks Using Range (Attaques par déni de service utilisant Range)

Les requêtes de plages multiples non contraintes sont susceptibles aux attaques par déni de service car l'effort requis pour demander de nombreuses plages chevauchantes des mêmes données est minime par rapport au temps, à la mémoire et à la bande passante consommés en tentant de servir les données demandées en de nombreuses parties. Les serveurs devraient ignorer, fusionner ou rejeter les requêtes de plages excessives, telles que les requêtes pour plus de deux plages chevauchantes ou pour de nombreuses petites plages dans un seul ensemble, en particulier lorsque les plages sont demandées dans le désordre sans raison apparente. Les requêtes de plages multiples ne sont pas conçues pour supporter l'accès aléatoire.

17.16. Authentication Considerations (Considérations sur l'authentification)

Tout ce qui concerne le sujet de l'authentification HTTP est une considération de sécurité, donc la liste des considérations ci-dessous n'est pas exhaustive. De plus, elle se limite aux considérations de sécurité concernant le cadre d'authentification, en général, plutôt que de discuter de toutes les considérations potentielles pour des schémas d'authentification spécifiques (qui devraient être documentées dans les spécifications qui définissent ces schémas). Diverses organisations maintiennent des informations thématiques et des liens vers la recherche actuelle sur la sécurité des applications Web (par exemple, [OWASP]), y compris les pièges courants pour l'implémentation et l'utilisation des schémas d'authentification trouvés en pratique.

17.16.1. Confidentiality of Credentials (Confidentialité des informations d'identification)

Le cadre d'authentification HTTP ne définit pas un mécanisme unique pour maintenir la confidentialité des informations d'identification; au lieu de cela, chaque schéma d'authentification définit comment les informations d'identification sont encodées avant la transmission. Bien que cela offre une flexibilité pour le développement de futurs schémas d'authentification, c'est insuffisant pour la protection des schémas existants qui ne fournissent pas de confidentialité par eux-mêmes, ou qui ne protègent pas suffisamment contre les attaques par rejeu. De plus, si le serveur attend des informations d'identification spécifiques à chaque utilisateur individuel, l'échange de ces informations d'identification aura pour effet d'identifier cet utilisateur même si le contenu des informations d'identification reste confidentiel.

HTTP dépend des propriétés de sécurité de la connexion de niveau transport ou session sous-jacente pour fournir une transmission confidentielle des champs. Les services qui dépendent de l'authentification utilisateur individuelle nécessitent une connexion sécurisée avant d'échanger des informations d'identification (Section 4.2.2).

17.16.2. Credentials and Idle Clients (Informations d'identification et clients inactifs)

Les clients HTTP et agents utilisateurs existants conservent généralement les informations d'authentification indéfiniment. HTTP ne fournit pas de mécanisme pour que le serveur d'origine ordonne aux clients de rejeter ces informations d'identification mises en cache, car le protocole n'a pas connaissance de la façon dont les informations d'identification sont obtenues ou gérées par l'agent utilisateur. Les mécanismes d'expiration ou de révocation des informations d'identification peuvent être spécifiés dans le cadre d'une définition de schéma d'authentification.

Les circonstances dans lesquelles la mise en cache des informations d'identification peut interférer avec le modèle de sécurité de l'application incluent, mais ne sont pas limitées à:

• Les machines clientes qui sont laissées inactives, sans surveillance par l'utilisateur, après quoi le serveur pourrait souhaiter amener le client à re-demander les informations d'identification à l'utilisateur.

• Les applications qui incluent une indication de fin de session (comme un bouton "déconnexion" ou "soumettre" sur une page) après laquelle le côté serveur de l'application "sait" qu'il n'y a plus de raison pour le client de conserver les informations d'identification.

Les agents utilisateurs qui mettent en cache les informations d'identification sont encouragés à fournir un mécanisme facilement accessible pour rejeter les informations d'identification mises en cache sous contrôle de l'utilisateur.

17.16.3. Protection Spaces (Espaces de protection)

Les schémas d'authentification qui s'appuient uniquement sur le mécanisme "realm" pour établir un espace de protection exposeront les informations d'identification à toutes les ressources sur un serveur d'origine. Les clients qui ont réussi à faire une requête authentifiée à une ressource peuvent utiliser les mêmes informations d'authentification pour d'autres ressources sur le même serveur d'origine. Cela permet à une ressource différente de récolter les informations d'authentification pour d'autres ressources.

Cela est particulièrement préoccupant lorsqu'un serveur d'origine héberge des ressources pour plusieurs parties sous la même origine (Section 11.5). Les stratégies d'atténuation possibles incluent la restriction de l'accès direct aux informations d'authentification (c'est-à-dire, ne pas rendre le contenu du champ d'en-tête de requête Authorization disponible), et la séparation des espaces de protection en utilisant un nom d'hôte différent (ou numéro de port) pour chaque partie.

17.16.4. Additional Response Fields (Champs de réponse supplémentaires)

L'ajout d'informations aux réponses envoyées sur une connexion non chiffrée peut divulguer des informations sur les communications sécurisées (autres). Par exemple, certaines extensions à un schéma d'authentification utilisent les champs d'en-tête Authentication-Info ou Proxy-Authentication-Info pour fournir des informations sur les requêtes ultérieures, telles que le prochain nonce à utiliser, qui peuvent aider à prévenir les attaques par rejeu. Si de telles informations sont communiquées sur une connexion non chiffrée, un attaquant pourrait les observer et ainsi réduire leur efficacité.