RFC du protocole HTTP : Sécurité

Cette section est une information à destination des développeurs d'applications, hébergeurs de données, et des utilisateurs, concernant les limites de sécurisation atteintes par HTTP/1.0 tel que décrit dans ce document. La discussion suivante ne prétend pas apporter de solution opérationnelle aux défauts qui y sont révélés, bien que quelques suggestions y soient faites pour réduire le risque informatique.

12.1 Authentification des clients

Comme le mentionne la Section 11.1, le modèle d'authentification "de base" n'est pas une méthode infaillible pour prévenir des accès non autorisés. Il ne peut non plus empêcher la transmission du corps d'entité "en clair" sur le réseau physique utilisé comme porteuse. HTTP/1.0 n'interdit aucunement l'emploi d'autres modèles, ou autres mécanismes de protection afin d'accroître la sécurité de transmission.

12.2 Méthodes sûres

Les éditeurs de logiciels clients doivent garder à l'esprit que leur application représente l'utilisateur dans ses interactions avec Internet, et doivent de ce fait s'assurer que l'utilisateur sera averti de toute action que l'application peut entamer, et susceptible d'avoir un résultat inattendu, tant pour eux que pour les tiers.

En particulier, il a été établi par convention que les méthodes GET et HEAD ne peuvent signifier autre chose qu'une demande de récupération de ressource. Ces méthodes peuvent être considérées comme "sûres". Ceci laisse la possibilité aux clients d'implémenter d'autres méthodes (ex. POST) sous une forme spécifique, mais toujours à condition que l'utilisateur puisse être averti qu'une action peu sûre ou potentiellement non conforme est requise.

Naturellement, il n'est pas possible de garantir que le serveur n'aura pas "d'effets de bord" lorsqu'il traite une requête GET; en fait, certaines ressources dynamiques tirent avantage de cette possibilité. La seule distinction de taille est que l'utilisateur qui émet une requête sûre de type GET n'a pas "dans l'intention" de provoquer ces effets de bord. Il ne peut donc en être tenu pour responsable.

12.3 Abus de l'information Server Log Information

Un serveur a toute possibilité de stocker des données personnelles contenues dans les requêtes telles qu'adresses et modèles d'accès ou en déduire et archiver des conclusions personnelles sur les goûts, les tendances ou les centres d'intérêt des utilisateurs. Ces informations sont par nature typiquement confidentielles et peuvent tomber sous le coup de la loi dans certains pays (NdT: typiquement dans le cadre de la loi "informatique et libertés", dans la mesure où un archivage systématique et une interprétation "sociologique" nominative sont réalisés). Les personnes utilisant le protocole HTTP pour diffuser des données ont la responsabilité de s'assurer que toute information reçue pouvant identifier et classifier les visiteurs ne puissent être communiquée sans l'accord de ces derniers.

12.4 Transfert d'information sensible

Comme tout protocole de transmission de donnée de base, HTTP ne peut contrôler la nature des informations transmises. Il n'est pas non plus possible à priori de déterminer la "sensibilité" de certaines portions de données transmises dans le cadre d'une requête quelle qu'elle soit. C'est pourquoi les applications devront prendre en charge la plus grande part du contrôle de ces informations en lieu et place du diffuseur. Trois champs d'en-tête sont particulièrement concernés par cette notion: Server, Referer et From.

Révéler la version exacte du logiciel serveur peut rendre celui-ci vulnérable aux attaques si le logiciel est réputé avoir des faiblesses en termes de sécurité. Le renseignement du champ Server doit de ce fait rester optionnel, et ne doit pas forcément être systématique.

Le champ Referer autorise l'étude d'un certain nombre d'informations à propos de la requête et permet de "remonter" une chaîne de liens. Bien que cette fonction soit très utile, il est possible néanmoins d'en abuser si les informations sur l'utilisateur ne sont pas dissociées de celles contenues dans le Referer. Même lorsque ces informations "personnelles" sont enlevées, le champ Referer peut parfois indiquer l'URI d'un document privé dont la publication n'est pas souhaitable.

L'information émise dans le champ From peut entrer en conflit avec la défense des droits privés, ou peut diminuer le degré de sécurité du serveur dans lequel la ressource est émise de ce fait, toute implémentation devra laisser la possibilité à l'utilisateur d'émettre, ne pas émettre, ou modifier les données dans ce champ. L'utilisateur devra être en mesure de configurer une valeur "par défaut" ou une "préférence utilisateur" pour les données dans ce champ.

Nous suggérons, mais n'imposons pas, qu'un interrupteur graphique soit implémenté sur l'interface utilisateur pour permettre ou interdire l'envoi des informations From et Referer.

12.5 Attaques sur les Fichiers et Répertoires

Les implémentations des serveurs origine HTTP devront veiller à restreindre la transmission des documents demandés par une requête HTTP aux seuls documents autorisés par l'administration système. Si un serveur HTTP traduit les URI HTTP directement en appels système de fichiers, le serveur devra veiller à ne pas livrer de documents destinés à autre chose qu'un client HTTP. Par exemple, Unix, Microsoft Windows, et d'autres systèmes d'exploitation utilisent ".." comme accès symbolique au répertoire de niveau supérieur. Sur un tel système, un serveur HTTP doit refuser une telle construction dans l'URI-visée, interdisant ainsi l'accès potentiel à des données qui ne sont pas sensées être diffusées par un serveur HTTP. De même, tous les fichiers à usage interne au serveur (fichiers de contrôle d'accès, de configuration, et codes script) doivent être protégés contre toute diffusion, dans la mesure où ils peuvent contenir des informations essentielles et confidentielles. L'expérience a montré que des imperfections mineures du logiciel serveur ont pu conduire à un réel risque en terme de sécurité.