Améliorez la sécurité et la confidentialité en mettant à jour le cache HTTP

Oublier ou utiliser de manière abusive l'en-tête Cache-Control peut avoir un impact négatif sur la sécurité de votre site Web et la confidentialité de vos utilisateurs.

Arthur Sonzogni
Arthur Sonzogni

Par défaut, les ressources peuvent toujours être mises en cache par n'importe quel type de cache. Ne pas utiliser ou utiliser de manière abusive l'en-tête Cache-Control peut avoir un impact négatif sur la sécurité de votre site Web et la confidentialité de vos utilisateurs.

Pour les réponses personnalisées que vous souhaitez conserver privées, nous vous recommandons de:

  • Empêcher les intermédiaires de mettre en cache la ressource. Définissez Cache-Control: private.
  • Définissez une clé de cache secondaire appropriée. Si la réponse varie en raison des cookies (ce qui peut se produire lorsque le cookie stocke des identifiants), définissez Vary: Cookie.

Lisez la suite pour découvrir pourquoi c'est important et pour en savoir plus:

  1. Problèmes de sécurité et de confidentialité que vous ne connaissez peut-être pas
  2. Différents types de caches HTTP et idées fausses courantes
  3. Actions recommandées pour les sites Web à forte valeur ajoutée

Ressources fuiteuses dues aux failles Spectre

La vulnérabilité Spectre permet à une page de lire la mémoire d'un processus d'OS. Cela signifie qu'un pirate informatique peut accéder de manière non autorisée aux données multi-origines. Par conséquent, les navigateurs Web modernes ont limité l'utilisation de certaines de leurs fonctionnalités, telles que SharedArrayBuffer ou le minuteur haute résolution, aux pages avec isolation cross-origin.

Les navigateurs Web modernes appliquent le Règlement de l'intégrateur multi-origine (COEP). Cela garantit que les ressources multi-origines sont:

  • Ressources publiques, demandées sans cookies
  • Ressources explicitement autorisées à être partagées entre origines, via CORS ou l'en-tête CORP

La configuration COEP n'empêche pas un pirate informatique d'exploiter Spectre. Toutefois, il garantit que les ressources multi-origines ne sont pas intéressantes pour l'attaquant (lorsqu'elles sont chargées par le navigateur en tant que ressource publique) ni autorisées à être partagées avec l'attaquant (lorsqu'elles sont partagées avec CORP: cross-origin).

Comment la mise en cache HTTP affecte-t-elle Spectre ?

Si l'en-tête Cache-Control n'est pas correctement défini, un pirate informatique peut lancer une attaque. Exemple :

  1. La ressource avec identifiants est mise en cache.
  2. L'attaquant charge une page isolée multi-origine.
  3. Le pirate informatique demande à nouveau la ressource.
  4. COEP:credentialless est défini par le navigateur. La ressource est donc récupérée sans cookies. Toutefois, un cache peut renvoyer la réponse avec identifiants à la place.
  5. Le pirate informatique peut ensuite lire la ressource personnalisée à l'aide d'une attaque Spectre.

Bien que le cache HTTP d'un navigateur Web ne permette pas ce type d'attaque en pratique, des caches supplémentaires existent en dehors du contrôle immédiat du navigateur. Cela peut entraîner la réussite de cette attaque.

Idées reçues courantes sur les caches HTTP

1. Les ressources sont mises en cache par le navigateur uniquement

Il existe souvent plusieurs niveaux de cache. Certains caches sont dédiés à un seul utilisateur, d'autres à plusieurs utilisateurs. Certains sont contrôlés par le serveur, d'autres par l'utilisateur et d'autres par des intermédiaires.

  • Caches du navigateur Ces caches appartiennent à un seul utilisateur et sont dédiés à celui-ci. Ils sont implémentés dans son navigateur Web. Ils améliorent les performances en évitant d'extraire la même réponse plusieurs fois.
  • Proxy local. Il peut avoir été installé par l'utilisateur, mais peut également être géré par des intermédiaires: son entreprise, son organisation ou son fournisseur d'accès à Internet. Les proxys locaux mettent souvent en cache une seule réponse pour plusieurs utilisateurs, ce qui constitue un cache "public". Les proxys locaux ont plusieurs rôles.
  • Cache / CDN du serveur d'origine Ce comportement est contrôlé par le serveur. L'objectif du cache du serveur d'origine est de réduire la charge sur le serveur d'origine en mettant en cache la même réponse pour plusieurs utilisateurs. Les objectifs d'un CDN sont similaires, mais répartis dans le monde entier et attribués à l'ensemble d'utilisateurs le plus proche afin de réduire la latence.
Il existe souvent plusieurs niveaux de cache entre le navigateur et le serveur.
Il peut y avoir plusieurs couches de cache entre le navigateur et le serveur. Par exemple, vous pouvez rencontrer un cache de serveur, suivi d'un CDN et du cache du navigateur. Un proxy local peut également être configuré entre le CDN et le cache du navigateur.

2. SSL empêche les intermédiaires de mettre en cache les ressources HTTPS.

De nombreux utilisateurs utilisent régulièrement des proxys configurés localement, que ce soit à des fins d'accès (par exemple, pour partager une connexion limitée), d'inspection des virus ou de protection contre la perte de données (DLP). Le cache intermédiaire effectue une interception TLS.

Un cache intermédiaire est souvent installé sur les postes de travail des employés d'une entreprise. Les navigateurs Web sont configurés pour approuver les certificats du proxy local.

En fin de compte, certaines ressources HTTPS peuvent être mises en cache par ces proxys locaux.

Fonctionnement du cache HTTP

  • Par défaut, les ressources peuvent être implicitement mises en cache.
  • La clé de cache principale se compose de l'URL et de la méthode. (URL, method)
  • La clé de cache secondaire correspond aux en-têtes inclus dans l'en-tête Vary. Vary: Cookie indique que la réponse dépend de Cookie.
  • L'en-tête Cache-Control offre un contrôle plus précis.

Les développeurs de sites Web à forte valeur ajoutée, y compris les sites Web à fort trafic et ceux qui interagissent avec des informations d'identification personnelle, doivent agir dès maintenant pour améliorer la sécurité.

Le risque le plus élevé se produit lorsque l'accès à une ressource varie en fonction des cookies. Un cache intermédiaire peut renvoyer une réponse demandée avec des cookies pour une requête qui ne l'était pas si aucune mesure préventive n'a été prise.

Nous vous recommandons de suivre l'une des étapes suivantes:

  • Empêcher les intermédiaires de mettre en cache la ressource. Définissez Cache-Control: private.
  • Définissez une clé de cache secondaire appropriée. Si la réponse varie en raison des cookies (ce qui peut se produire lorsque le cookie stocke des identifiants), définissez Vary: Cookie.

Plus précisément, modifiez le comportement par défaut: définissez toujours Cache-Control ou Vary.

Informations complémentaires

Il existe d'autres types d'attaques similaires qui utilisent le cache HTTP, mais ceux-ci reposent sur un mécanisme différent de l'isolation inter-origine. Par exemple, Jake Archibald décrit certaines attaques dans How to win at CORS (Comment gagner avec CORS).

Ces attaques sont atténuées par certains navigateurs Web qui divisent leur cache HTTP selon que la réponse de la ressource a été demandée avec des identifiants ou non. Depuis 2022, Firefox divise le cache, tandis que Chrome et Safari ne le font pas. Chrome pourra diviser le cache à l'avenir. Notez que ces attaques sont différentes et complémentaires de la division par origine de premier niveau.

Même si ce problème peut être atténué pour les navigateurs Web, il restera dans les caches proxy locaux. Nous vous recommandons donc de suivre les recommandations ci-dessus.

Photo de l'en-tête par Ben Pattinson sur Unsplash.