HTTP-Cache aktualisieren und Sicherheit und Datenschutz verbessern

Wenn Sie den Cache-Control-Header vergessen oder missbrauchen, kann sich das negativ auf die Sicherheit Ihrer Website und den Datenschutz Ihrer Nutzer auswirken.

Arthur Sonzogni
Arthur Sonzogni

Standardmäßig dürfen Ressourcen immer in jedem Cache-Typ zwischengespeichert werden. Wenn Sie die Cache-Control-Überschrift nicht verwenden oder missbrauchen, kann dies sich negativ auf die Sicherheit Ihrer Website und die Privatsphäre Ihrer Nutzer auswirken.

Wenn Sie personalisierte Antworten privat halten möchten, empfehlen wir Ihnen Folgendes:

  • Verhindern, dass Zwischenhändler die Ressource im Cache speichern. Legen Sie Cache-Control: private fest.
  • Legen Sie einen geeigneten sekundären Cache-Schlüssel fest. Wenn die Antwort aufgrund von Cookies variiert, was passieren kann, wenn das Cookie Anmeldedaten speichert, legen Sie Vary: Cookie fest.

Im Folgenden erfahren Sie, warum das wichtig ist und welche Vorteile es bietet:

  1. Sicherheits- und Datenschutzprobleme, die Sie möglicherweise nicht kennen
  2. Verschiedene Arten von HTTP-Caches und häufige Missverständnisse
  3. Empfohlene Maßnahmen für Websites mit hohem Umsatzpotenzial

Ressourcenlecks durch Spectre-Sicherheitslücken

Die Spectre-Sicherheitslücke ermöglicht es einer Seite, den Arbeitsspeicher eines Betriebssystemprozesses zu lesen. Das bedeutet, dass ein Angreifer unbefugten Zugriff auf datenquellenübergreifende Daten erhalten kann. Daher haben moderne Webbrowser die Verwendung einiger ihrer Funktionen wie SharedArrayBuffer oder Timer mit hoher Auflösung auf Seiten mit Isolation zwischen verschiedenen Ursprüngen beschränkt.

Moderne Webbrowser erzwingen die Cross-Origin-Embedder-Richtlinie (COEP). So wird sichergestellt, dass plattformübergreifende Ressourcen entweder

  • Öffentliche Ressourcen, die ohne Cookies angefordert werden
  • Ressourcen, die explizit über CORS oder den CORP-Header für die plattformübergreifende Freigabe zugelassen sind

Die COEP-Einrichtung verhindert nicht, dass ein Angreifer Spectre ausnutzt. Es wird jedoch sichergestellt, dass plattformübergreifende Ressourcen für den Angreifer nicht wertvoll sind (wenn sie vom Browser als öffentliche Ressource geladen werden) oder nicht mit dem Angreifer geteilt werden dürfen (wenn sie mit CORP: cross-origin geteilt werden).

Wie wirkt sich das HTTP-Caching auf Spectre aus?

Wenn der Cache-Control-Header nicht richtig festgelegt ist, kann ein Angreifer einen Angriff ausführen. Beispiel:

  1. Die Ressource mit Anmeldedaten wird im Cache gespeichert.
  2. Der Angreifer lädt eine ursprungsübergreifend isolierte Seite.
  3. Der Angreifer fordert die Ressource noch einmal an.
  4. COEP:credentialless wird vom Browser festgelegt, sodass die Ressource ohne Cookies abgerufen wird. Ein Cache kann jedoch stattdessen die Antwort mit Anmeldedaten zurückgeben.
  5. Der Angreifer kann dann die personalisierte Ressource mit einem Spectre-Angriff lesen.

Obwohl diese Art von Angriff durch den HTTP-Cache eines Webbrowsers in der Praxis nicht möglich ist, gibt es zusätzliche Caches, die nicht direkt vom Browser verwaltet werden. Dies kann zum Erfolg dieses Angriffs führen.

Häufige Missverständnisse über HTTP-Caches

1. Ressourcen werden nur vom Browser im Cache gespeichert

Es gibt oft mehrere Cacheebenen. Einige Caches sind für einen einzelnen Nutzer, andere für mehrere Nutzer vorgesehen. Einige werden vom Server, andere vom Nutzer und wieder andere von Intermediären gesteuert.

  • Browser-Caches Diese Caches gehören einem einzelnen Nutzer und sind in seinem Webbrowser implementiert. Sie verbessern die Leistung, da dieselbe Antwort nicht mehrmals abgerufen werden muss.
  • Lokaler Proxy Dieser kann vom Nutzer installiert worden sein, aber auch von einem Intermediär verwaltet werden: seinem Unternehmen, seiner Organisation oder seinem Internetanbieter. Lokale Proxys speichern oft eine einzelne Antwort für mehrere Nutzer im Cache, was einen „öffentlichen“ Cache darstellt. Lokale Proxys haben mehrere Rollen.
  • Ursprungsserver-Cache / CDN Das wird vom Server gesteuert. Ziel des Origin-Server-Caches ist es, die Belastung des Origin-Servers zu verringern, indem dieselbe Antwort für mehrere Nutzer im Cache gespeichert wird. Die Ziele eines CDN sind ähnlich, aber es ist auf der ganzen Welt verteilt und wird den Nutzern zugewiesen, die am nächsten sind, um die Latenz zu reduzieren.
Zwischen dem Browser und dem Server gibt es oft mehrere Cacheebenen.
Zwischen dem Browser und dem Server können sich mehrere Cacheebenen befinden. Es kann beispielsweise ein Servercache, gefolgt von einem CDN und dem Browsercache geben. Möglicherweise ist auch ein lokaler Proxy zwischen dem CDN und dem Browser-Cache eingerichtet.

2. SSL verhindert, dass Zwischenhändler HTTPS-Ressourcen im Cache speichern

Viele Nutzer verwenden regelmäßig lokal konfigurierte Proxys, z. B. für den Zugriff (z. B. Freigabe einer getakteten Verbindung), die Virenprüfung oder die Datenverlustprävention (DLP). Der Zwischencache führt eine TLS-Abfangung durch.

Ein Zwischencache wird oft auf den Workstations der Mitarbeiter eines Unternehmens installiert. Webbrowser sind so konfiguriert, dass sie den Zertifikaten des lokalen Proxys vertrauen.

Letztendlich können einige HTTPS-Ressourcen von diesen lokalen Proxys im Cache gespeichert werden.

Funktionsweise des HTTP-Cache

  • Ressourcen dürfen standardmäßig implizit im Cache gespeichert werden.
  • Der primäre Cache-Schlüssel besteht aus der URL und der Methode. (URL, method)
  • Der sekundäre Cache-Schlüssel besteht aus den Headern, die im Vary-Header enthalten sind. Vary: Cookie gibt an, dass die Antwort vom Cookie abhängt.
  • Die Cache-Control-Überschrift bietet eine detailliertere Kontrolle.

Entwickler von Websites mit hohem Wert, darunter Websites mit hohem Traffic und Websites, die mit personenidentifizierbaren Informationen interagieren, sollten jetzt Maßnahmen zur Verbesserung der Sicherheit ergreifen.

Das größte Risiko besteht, wenn der Zugriff auf eine Ressource von Cookies abhängt. Ein Zwischencache kann eine Antwort zurückgeben, die mit Cookies für eine Anfrage angefordert wurde, die keine Cookies enthielt, wenn keine vorbeugenden Maßnahmen ergriffen wurden.

Wir empfehlen Ihnen, einen der folgenden Schritte auszuführen:

  • Verhindern, dass Zwischenhändler die Ressource im Cache speichern. Legen Sie Cache-Control: private fest.
  • Legen Sie einen geeigneten sekundären Cache-Schlüssel fest. Wenn die Antwort aufgrund von Cookies variiert, was passieren kann, wenn das Cookie Anmeldedaten speichert, legen Sie Vary: Cookie fest.

Ändern Sie insbesondere das Standardverhalten: Definieren Sie immer Cache-Control oder Vary.

Weitere Überlegungen

Es gibt andere, ähnliche Arten von Angriffen, die den HTTP-Cache verwenden, aber diese basieren auf einem anderen Mechanismus als die seitenübergreifende Isolation. Jake Archibald beschreibt beispielsweise einige Angriffe in How to win at CORS.

Diese Angriffe werden von einigen Webbrowsern abgeschwächt, die ihren HTTP-Cache abhängig davon aufteilen, ob die Ressourcenantwort mit oder ohne Anmeldedaten angefordert wurde. Stand 2022 teilt Firefox den Cache, während Chrome und Safari dies nicht tun. Chrome kann den Cache in Zukunft aufteilen. Hinweis: Diese Angriffe unterscheiden sich und ergänzen die Aufteilung nach dem Ursprung der obersten Ebene.

Auch wenn dieses Problem für Webbrowser gemildert werden kann, bleibt es in lokalen Proxy-Caches bestehen. Wir empfehlen Ihnen daher, die oben genannten Empfehlungen zu befolgen.

Titelbild von Ben Pattinson auf Unsplash.