7. Security Considerations (Considérations de sécurité)
Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des préoccupations de sécurité connues spécifiques à la mise en cache HTTP. Des considérations de sécurité plus générales sont abordées dans "HTTP/1.1" (section 11 de [HTTP/1.1]) et "HTTP Semantics" (section 17 de [HTTP]).
Les caches exposent une surface d'attaque supplémentaire car le contenu du cache représente une cible attrayante pour l'exploitation malveillante. Étant donné que le contenu du cache persiste à travers les requêtes HTTP, les attaques sur un cache peuvent révéler des informations longtemps après qu'un utilisateur croit que l'information a été supprimée du réseau. Par conséquent, le contenu du cache doit être protégé comme une information sensible.
En particulier, étant donné que les caches privés sont limités à un seul utilisateur, ils peuvent être utilisés pour reconstruire l'activité d'un utilisateur. Il est donc important que les agents utilisateurs donnent à l'utilisateur final le contrôle sur eux, par exemple, en lui permettant de supprimer les réponses stockées pour certains ou tous les serveurs d'origine.
7.1 Cache Poisoning (Empoisonnement du cache)
Le stockage de contenu malveillant dans un cache peut amplifier la portée d'un attaquant pour affecter plusieurs utilisateurs. Cette attaque "d'empoisonnement du cache (Cache Poisoning)" se produit lorsqu'un attaquant utilise des failles d'implémentation, des privilèges élevés ou d'autres techniques pour insérer une réponse dans un cache. Cela est particulièrement efficace lorsqu'un cache partagé est utilisé pour distribuer du contenu malveillant à de nombreux clients.
Un vecteur courant pour les attaques d'empoisonnement du cache consiste à exploiter les différences d'analyse des messages entre les proxys et les agents utilisateurs ; voir la section 6.3 de [HTTP/1.1] pour les exigences pertinentes.
7.2 Timing Attacks (Attaques temporelles)
Étant donné que l'une des principales utilisations d'un cache est d'optimiser les performances, son utilisation peut "fuir (Leak)" des informations sur les ressources qui ont été précédemment demandées.
Par exemple, si un utilisateur visite un site et que son navigateur met en cache certaines de ses réponses, puis navigue vers un deuxième site, ce site peut tenter de charger des réponses qu'il sait exister sur le premier site. Si elles se chargent rapidement, on peut supposer que l'utilisateur a visité ce site, ou même une page spécifique dessus.
Ces "attaques temporelles (Timing Attacks)" peuvent être atténuées en ajoutant plus d'informations à la clé de cache (par exemple, l'identité du site référent, pour empêcher l'attaque décrite ci-dessus). Ceci est parfois appelé "double keying (Double Keying)".
7.3 Caching of Sensitive Information (Mise en cache d'informations sensibles)
Les failles d'implémentation et de déploiement (souvent dues à une incompréhension du fonctionnement du cache) peuvent entraîner la mise en cache d'informations sensibles (telles que les informations d'identification d'authentification), les exposant ainsi à des parties non autorisées.
Notez que le champ d'en-tête de réponse Set-Cookie [COOKIE] n'inhibe pas la mise en cache ; une réponse cachable avec un champ d'en-tête Set-Cookie peut être (et est souvent) utilisée pour satisfaire les requêtes ultérieures au cache. Les serveurs qui souhaitent contrôler la mise en cache de ces réponses sont encouragés à émettre des champs d'en-tête de réponse Cache-Control appropriés.