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

L'oubli ou l'utilisation abusive de l'en-tête Cache-Control peuvent avoir un impact négatif sur la sécurité de votre site Web et la confidentialité des utilisateurs.

Arthur Sonzogni
Arthur Sonzogni

Par défaut, tout type de cache autorise la mise en cache des ressources. Si vous n'utilisez pas ou de manière abusive l'en-tête Cache-Control, vous risquez d'avoir un impact négatif sur la sécurité de votre site Web et la confidentialité de vos utilisateurs.

Pour obtenir des réponses personnalisées qui doivent rester privées, nous vous recommandons d'effectuer l'une des opérations suivantes:

  • Empêchez 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 (qui peuvent se produire lorsque le cookie stocke les identifiants), définissez Vary: Cookie.

Lisez la suite pour en savoir plus et découvrir:

  1. Problèmes de sécurité et de confidentialité dont vous n'avez peut-être pas connaissance
  2. Différents types de caches HTTP et idées reçues
  3. Actions recommandées pour les sites Web à fort potentiel

Fuite de ressources provenant de failles Spectre

La faille Spectre permet à une page de lire la mémoire d'un processus du système d'exploitation. Cela signifie qu'un pirate informatique peut obtenir un accès non autorisé à des 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 présentant une isolation multi-origine.

Les navigateurs Web récents appliquent la règle 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 en multi-origine, via CORS ou l'en-tête CORP.

La configuration COEP n’empêche pas un attaquant d’exploiter Spectre. Toutefois, cela garantit que les ressources multi-origines ne sont pas utiles pour le pirate informatique (lorsqu'elles sont chargées par le navigateur en tant que ressources publiques) ou autorisées à être partagées avec le pirate (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 pourrait lancer une attaque. Exemple :

  1. La ressource avec identifiants est mise en cache.
  2. Le pirate informatique charge une page isolée multi-origine.
  3. L'attaquant demande à nouveau la ressource.
  4. COEP:credentialless est défini par le navigateur. La ressource est donc extraite 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 en pratique ce type d'attaque, il existe des caches supplémentaires qui échappent au contrôle immédiat du navigateur. Cela peut conduire à la réussite de cette attaque.

Idées reçues sur les caches HTTP

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

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

  • Caches du navigateur : Ces caches sont détenus et dédiés à un seul utilisateur, et sont implémentés dans son navigateur Web. Ils améliorent les performances en évitant de récupérer la même réponse plusieurs fois.
  • Proxy local : Celui-ci a peut-être é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 du serveur d'origine / CDN. Ce paramètre 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 assignés à l'ensemble d'utilisateurs le plus proche afin de réduire la latence.
Il existe souvent plusieurs couches de cache entre le navigateur et le serveur.
Il peut y avoir différentes 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. Il peut également y avoir une configuration de proxy local 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 facturée à l'usage), pour inspecter des virus ou pour prévenir la perte de données. 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

  • La mise en cache des ressources est implicitement par défaut.
  • La clé de cache principale comprend l'URL et la méthode. (URL, méthode)
  • 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 de grande valeur, qui incluent des sites Web très fréquentés et des sites qui interagissent avec des informations d'identification personnelles, doivent agir dès maintenant pour renforcer 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 qui a été demandée avec des cookies pour une requête qui ne l'a pas été si aucune mesure préventive n'a été prise.

Nous vous recommandons d'effectuer l'une des opérations suivantes:

  • Empêchez 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 (qui peuvent se produire lorsque le cookie stocke les identifiants), définissez Vary: Cookie.

Modifiez en particulier le comportement par défaut: définissez toujours Cache-Control ou Vary.

Facteurs supplémentaires

Il existe d'autres types d'attaques similaires utilisant le cache HTTP, mais ceux-ci reposent sur un mécanisme différent de l'isolation multi-origine. Par exemple, Jake Archibald décrit certaines attaques dans la section Comment gagner sur 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, contrairement à Chrome et Safari. Chrome est susceptible de diviser le cache à l'avenir. Notez que ces attaques sont différentes et complémentaires à la répartition des attaques par origine de niveau supérieur.

Même si ce problème peut être atténué pour les navigateurs Web, il persiste dans les caches proxy locaux. Par conséquent, nous vous suggérons toujours de suivre les recommandations ci-dessus.

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