9. Considérations de sécurité (Security Considerations)
Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des problèmes de sécurité connus pertinents pour la sémantique HTTP et son utilisation pour transférer des informations sur Internet. Les considérations relatives à la syntaxe, à l'analyse et au routage des messages sont discutées dans [RFC7230], et les considérations relatives à la mise en cache HTTP sont discutées dans [RFC7234].
La liste des considérations ci-dessous n'est pas exhaustive. La plupart des préoccupations de sécurité liées à 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 des informations obtenues à partir des champs d'en-tête HTTP. Beaucoup de ces préoccupations sont interdépendantes; une faiblesse dans le logiciel client peut être utilisée pour exploiter des vulnérabilités dans le logiciel serveur, et vice versa.
9.1. Attaques basées sur les noms de fichiers et de chemins (Attacks Based on File and Path Names)
Les serveurs d'origine utilisent fréquemment leur système de fichiers local pour gérer le mappage de l'URI cible vers les représentations de ressources. La plupart des systèmes de fichiers ne sont pas conçus pour protéger contre les noms de fichiers ou de chemins malveillants. Par conséquent, un serveur d'origine doit éviter d'accéder à des noms qui ont une signification spéciale pour le système lors du mappage de la ressource cible vers des fichiers, dossiers ou 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 dénomination 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 à privilégier la convivialité plutôt que la sécurité lors du traitement de caractères invalides ou inattendus, en les recomposant de manières qui peuvent entraîner des motifs non intentionnels.
Les implémentations doivent veiller à ne pas échapper ou déséchapper la même chaîne plus d'une fois, car le désechappement d'une chaîne précédemment échappée peut entraîner des caractères dangereux. En particulier, il n'est pas sûr de simplement déséchapper la cible de requête et de l'utiliser comme chemin de système de fichiers sans vérifications supplémentaires.
Notez que les restrictions sur les URI cibles dans cette spécification ne sont pas suffisantes pour prévenir ces types d'attaques; elles doivent être complétées par des vérifications spécifiques à l'implémentation.
9.2. Attaques basées sur l'injection de commandes, de code ou de requêtes (Attacks Based on Command, Code, or Query Injection)
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 fiables. Un attaquant pourrait construire n'importe quel élément de données de requête (méthode, cible de requête, champs d'en-tête ou corps) pour contenir des données qui pourraient être mal interprétées comme une commande, du code ou une requête lorsqu'elles sont transmises via un appel 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 la cible de requête 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 SQL 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, bien qu'il soit facile à prévenir.
En général, les implémentations de ressources devraient (ought to) éviter l'utilisation de données de requête dans l'assemblage de commandes shell ou de requêtes. Lorsqu'une telle utilisation est nécessaire, les données doivent être correctement échappées (de manière appropriée pour le système recevant les données) avant d'être utilisées.
9.3. Divulgation d'informations personnelles (Disclosure of Personal Information)
Les clients ont souvent accès à de grandes quantités d'informations personnelles, y compris à la fois des 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 des 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 non intentionnelle de telles informations.
9.3.1. Divulgation via les données d'application (Disclosure via Application Data)
Les applications devraient (ought to) limiter leur divulgation d'informations à ce qui est requis pour compléter la requête et éviter la divulgation d'informations spécifiques à l'utilisateur ou à la structure interne de l'application (Section 5.5.3 et Section 7.4.2).
9.3.2. Divulgation via Referer (Disclosure via Referer)
Le champ d'en-tête Referer permet à un client d'annoncer au serveur d'où le client a obtenu la cible de requête, ce qui peut révéler des informations sur le contexte de l'utilisateur ou son historique de navigation. Dans le cas où la cible de requête a été fournie par une source tierce, l'utilisateur pourrait souhaiter garder ces informations confidentielles (par exemple, un lien provenant d'informations médicales). L'agent utilisateur devrait donc (ought to) donner à l'utilisateur l'option de ne pas envoyer le champ Referer, ou d'envoyer une version moins révélatrice (par exemple, seulement l'origine) du champ (Section 5.5.2).
Les clients ne devraient pas (ought not to) inclure un champ d'en-tête Referer dans une requête HTTP (non sécurisée) si la page de référence a été reçue avec un protocole sécurisé.
Les auteurs de services qui utilisent le protocole HTTP ne devraient pas (ought not to) utiliser des requêtes GET et POST avec du contenu encodé en formulaire pour transmettre des informations sensibles telles que des informations d'identification personnelle, des numéros de compte, des mots de passe, etc., car cela entraîne la transmission non chiffrée de ces données dans la cible de requête ou le contenu. Les concepteurs de services devraient (ought to) utiliser la méthode POST avec des corps de message pour transmettre de telles informations sensibles, en veillant à ne pas inclure de telles informations dans la cible de requête, car cela pourrait être exposé dans les journaux, les signets, etc.
9.3.3. Divulgation via User-Agent (Disclosure via User-Agent)
Le champ d'en-tête User-Agent contient souvent 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 de l'utilisateur ou les extensions. Les implémentations devraient (ought to) limiter de telles informations (Section 5.5.3).
9.4. Confidentialité des informations du journal du serveur (Privacy of Server Log Information)
Un serveur est en position 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 sujets d'intérêt. En particulier, les informations de journal recueillies chez un intermédiaire contiennent souvent un historique d'interaction de l'agent utilisateur, sur une multitude de sites, qui peut être tracé jusqu'à des 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 que les traces de journal réelles ne soient 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 qui sont liées à un client spécifique devraient (ought to) être soit anonymisées, soit considérées comme confidentielles.
Pour minimiser le risque de vol ou de publication accidentelle, les informations de journal devraient (ought to) être purgées dès que possible.
9.5. Divulgation du fragment après les redirections (Disclosure of Fragment after Redirects)
Bien que les identificateurs de fragment utilisés dans les références URI ne soient pas envoyés dans les requêtes, les implémenteurs devraient (ought to) être conscients qu'ils seront visibles pour l'agent utilisateur et toutes les extensions ou scripts s'exécutant à la suite de la réponse. En particulier, lorsqu'une redirection se produit et que l'identificateur de fragment de la requête originale est hérité par la nouvelle référence dans Location (Section 7.1.2), cela pourrait avoir des conséquences en matière de sécurité.
9.6. Divulgation d'informations sur le produit (Disclosure of Product Information)
Les champs d'en-tête Server et User-Agent révèlent souvent des informations sur les systèmes logiciels de l'expéditeur respectif. En théorie, cela peut faciliter l'exploitation par un attaquant de failles de sécurité connues; en pratique, les attaquants ont tendance à essayer tous les trous potentiels indépendamment des versions de logiciel apparentes en cours d'utilisation.
Les proxys qui servent de portail à travers un pare-feu réseau devraient (ought to) prendre des précautions spéciales concernant le transfert d'informations d'en-tête qui pourraient identifier des 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.
9.7. Empreinte digitale du navigateur (Browser Fingerprinting)
L'empreinte digitale du navigateur est un ensemble de techniques permettant d'identifier un agent utilisateur spécifique au fil du temps grâce à 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 l'ensemble des caractéristiques uniques qui pourraient être communiquées via HTTP soit d'un intérêt particulier ici. L'empreinte digitale est considérée comme une préoccupation de confidentialité car elle permet le suivi du comportement d'un agent utilisateur au fil du temps (Section 9.4) sans les contrôles correspondants que l'utilisateur pourrait avoir sur d'autres formes de données, telles que les cookies.
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'on s'attende à ce que From ne soit envoyé que lorsque l'auto-identification est souhaitée par l'utilisateur. De même, les champs d'en-tête Cookie sont délibérément conçus pour permettre la ré-identification, de sorte que les préoccupations d'empreinte digitale ne s'appliquent que lorsque les cookies sont désactivés ou restreints par l'agent utilisateur.
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 de l'utilisateur ou les extensions. Cependant, la source d'informations uniques la moins attendue par les utilisateurs est la négociation proactive (Section 3.4.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 de nature privée. Par exemple, la compréhension d'un ensemble de langues donné pourrait être fortement corrélée à l'appartenance à un groupe ethnique particulier. Une approche qui limite une telle perte de confidentialité serait pour un agent utilisateur d'omettre l'envoi de Accept-Language sauf pour les sites qui ont été mis sur liste blanche, peut-être via une interaction après avoir détecté un champ d'en-tête Vary indiquant que la négociation linguistique pourrait être utile.
Dans les environnements où les proxys sont utilisés pour améliorer la confidentialité, les agents utilisateurs devraient (ought to) ê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 degré élevé de configurabilité des champs d'en-tête devraient (ought to) 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 proxys pourraient filtrer les champs d'en-tête de négociation proactive dans les requêtes relayées.
9.8. Rétention du validateur (Validator Retention)
Les validateurs contenus dans les métadonnées de réponse (Section 7.2) ne devraient (ought to) être conservés par un cache que pendant le temps nécessaire pour le traitement normal et l'expiration de la réponse mise en cache. Conserver les validateurs pendant des périodes prolongées peut entraîner des problèmes de confidentialité car les anciens validateurs pourraient être utilisés pour corréler l'activité d'un seul utilisateur sur plusieurs requêtes, même si le serveur n'associe pas explicitement les valeurs de validateur aux utilisateurs individuels. Les agents utilisateurs qui n'agissent pas en tant que cache ne devraient pas (ought not to) conserver les validateurs pendant des périodes prolongées.