Wenn Sie den Header „Cache-Control“ vergessen oder missbrauchen, kann dies die Sicherheit Ihrer Website und den Datenschutz Ihrer Nutzer beeinträchtigen.
Standardmäßig dürfen Ressourcen immer von jedem Cache-Typ im Cache gespeichert werden.
Wenn Sie den Header Cache-Control
nicht verwenden oder missbrauchen, kann dies die Sicherheit Ihrer Website und den Datenschutz Ihrer Nutzer beeinträchtigen.
Wenn Sie persönliche Antworten nicht erhalten möchten, empfehlen wir Ihnen Folgendes:
- Verhindert, dass Vermittler 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 Anmeldedaten im Cookie gespeichert werden, legen Sie
Vary: Cookie
fest.
Lesen Sie weiter, um zu erfahren, warum das wichtig ist, und erfahren Sie Folgendes:
- Sicherheits- und Datenschutzprobleme, die Sie vielleicht nicht kennen
- Verschiedene Arten von HTTP-Caches und häufige Missverständnisse
- Empfohlene Maßnahmen für hochwertige Websites
Cache-bezogene Sicherheits- und Datenschutzrisiken
Undichte Ressourcen aus Spectre-Sicherheitslücken
Aufgrund der Spectre-Sicherheitslücke kann eine Seite den Arbeitsspeicher eines Betriebssystemprozesses lesen. Dies bedeutet, dass ein Angreifer unbefugten Zugriff auf ursprungsübergreifende Daten erhalten kann. Aus diesem Grund können in modernen Webbrowsern einige Funktionen wie SharedArrayBuffer
oder der hochauflösende Timer nur eingeschränkt auf Seiten mit ursprungsübergreifender Isolierung genutzt werden.
Moderne Webbrowser erzwingen die Cross-Origin Embedder Policy (COEP). Dadurch werden ursprungsübergreifende Ressourcen entweder
- Öffentliche Ressourcen, ohne Cookies angefordert
- Ressourcen, die ausdrücklich ursprungsübergreifend freigegeben werden dürfen, über CORS oder den CORP-Header
Das COEP-Setup hindert einen Angreifer nicht daran, Spectre auszunutzen. Sie sorgt jedoch dafür, dass ursprungsübergreifende Ressourcen für den Angreifer nicht wertvoll sind (wenn sie vom Browser als öffentliche Ressource geladen werden) oder für den Angreifer freigegeben werden dürfen (wenn sie mit CORP: cross-origin
geteilt werden).
Wie wirkt sich HTTP-Caching auf Spectre aus?
Wenn der Header Cache-Control
nicht korrekt festgelegt ist, könnte ein Angreifer einen Angriff ausführen. Beispiel:
- Die Ressource mit den Anmeldedaten wird im Cache gespeichert.
- Der Angreifer lädt eine ursprungsübergreifende, isolierte Seite.
- Der Angreifer fordert die Ressource noch einmal an.
COEP:credentialless
wird vom Browser festgelegt, sodass die Ressource ohne Cookies abgerufen wird. Ein Cache kann jedoch stattdessen die Antwort mit Anmeldedaten zurückgeben.- Der Angreifer kann die personalisierte Ressource dann mithilfe eines Spectre-Angriffs lesen.
Obwohl der HTTP-Cache eines Webbrowsers diese Art von Angriff in der Praxis nicht zulässt, sind zusätzliche Caches außerhalb der unmittelbaren Kontrolle des Browsers vorhanden. Dies kann zum Erfolg dieses Angriffs führen.
Häufige Missverständnisse bezüglich HTTP-Caches
1. Ressourcen werden nur vom Browser im Cache gespeichert
Es gibt häufig mehrere Cache-Ebenen. Einige Caches sind für einen einzelnen Nutzer vorgesehen, andere für mehrere Nutzer. Einige werden vom Server gesteuert, andere vom Nutzer und andere von Vermittlern.
- Browser-Caches: Diese Caches gehören einem einzelnen Nutzer und sind nur einem Nutzer zugeordnet, der in seinem Webbrowser implementiert ist. Sie verbessern die Leistung, da nicht dieselbe Antwort mehrmals abgerufen werden muss.
- Lokaler Proxy. Diese Software wurde möglicherweise vom Nutzer installiert, kann aber auch von einem Mittler verwaltet werden: ihrem Unternehmen, ihrer Organisation oder ihrem Internetanbieter. Lokale Proxys speichern oft eine einzelne Antwort für mehrere Nutzer im Cache, was einen „öffentlichen“ Cache darstellt. Lokale Proxys haben mehrere Rollen.
- Cache des Ursprungsservers / CDN: Dies wird vom Server gesteuert. Das Ziel des Ursprungsserver-Caches besteht darin, die Last des Ursprungsservers zu reduzieren, indem dieselbe Antwort für mehrere Nutzer im Cache gespeichert wird. Die Ziele eines CDN sind ähnlich, aber auf die ganze Welt verteilt und den nächstgelegenen Nutzern zugewiesen, um die Latenz zu verringern.
2. SSL verhindert, dass HTTPS-Ressourcen im Cache gespeichert werden
Viele Nutzer verwenden regelmäßig lokal konfigurierte Proxys, um Zugriffsberechtigungen wie die gemeinsame Nutzung einer kostenpflichtigen Verbindung, Virenprüfung oder Schutz vor Datenverlust (Data Loss Prevention, DLP) zu ermöglichen. Der Zwischen-Cache fängt TLS ab.
Ein Zwischen-Cache wird häufig auf den Workstations eines Mitarbeiters installiert. Webbrowser sind so konfiguriert, dass sie den Zertifikaten des lokalen Proxys vertrauen.
Letztendlich werden einige HTTPS-Ressourcen von diesen lokalen Proxys im Cache gespeichert.
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, Methode)
- Der sekundäre Cache-Schlüssel sind die Header, die im
Vary
-Header enthalten sind.Vary: Cookie
gibt an, dass die Antwort vonCookie
abhängt. - Der
Cache-Control
-Header ermöglicht eine genauere Steuerung.
Diese empfohlenen Maßnahmen für Ihre Website ergreifen
Entwickler von hochwertigen Websites, darunter Websites mit hohem Traffic und Websites, die mit personenbezogenen Daten interagieren, sollten jetzt handeln, um die Sicherheit zu verbessern.
Das größte Risiko tritt auf, wenn der Zugriff auf eine Ressource je nach Cookies variiert. Ein Zwischen-Cache gibt möglicherweise eine Antwort zurück, die mit Cookies für eine andere Anfrage angefordert wurde, wenn keine Präventivmaßnahmen ergriffen wurden.
Wir empfehlen Ihnen, einen der folgenden Schritte auszuführen:
- Verhindert, dass Vermittler 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 Anmeldedaten im Cookie gespeichert werden, 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 bei der ursprungsübergreifenden Isolierung. Jake Archibald beschreibt beispielsweise einige Angriffe in How to win at CORS.
Diese Angriffe werden durch einige Webbrowser abgemildert, die ihren HTTP-Cache danach aufteilen, ob die Ressourcenantwort mit Anmeldedaten angefordert wurde oder nicht. Seit 2022 wird der Cache in Firefox aufgeteilt, in Chrome und Safari nicht. Chrome teilt den Cache in Zukunft möglicherweise auf. Beachten Sie, dass sich diese Angriffe unterscheiden und ergänzen, wenn sie nach dem Ursprung der obersten Ebene aufgeteilt werden.
Auch wenn dieses Problem für Webbrowser gemindert werden kann, bleibt es in lokalen Proxy-Caches bestehen. Wir empfehlen Ihnen daher, die oben genannten Empfehlungen zu befolgen.
Kopfzeilenfoto von Ben Pattinson auf Unsplash.