Zum Hauptinhalt springen

7. Security Considerations (Sicherheitsüberlegungen)

Dieser Abschnitt soll Entwickler, Informationsanbieter und Benutzer über bekannte, spezifisch für HTTP-Caching relevante Sicherheitsbedenken informieren. Allgemeinere Sicherheitsüberlegungen werden in "HTTP/1.1" (Abschnitt 11 von [HTTP/1.1]) und "HTTP Semantics" (Abschnitt 17 von [HTTP]) behandelt.

Caches exponieren eine zusätzliche Angriffsfläche, da der Inhalt des Caches ein attraktives Ziel für böswillige Ausnutzung darstellt. Da Cache-Inhalte über HTTP-Anfragen hinweg bestehen bleiben, können Angriffe auf einen Cache Informationen lange nach dem Zeitpunkt offenbaren, zu dem ein Benutzer glaubt, dass die Informationen aus dem Netzwerk entfernt wurden. Daher müssen Cache-Inhalte als sensible Informationen geschützt werden.

Insbesondere, da private Caches auf einen einzelnen Benutzer beschränkt sind, können sie verwendet werden, um die Aktivität eines Benutzers zu rekonstruieren. Daher ist es wichtig, dass User-Agents dem Endbenutzer Kontrolle über sie geben, zum Beispiel indem sie es ihm erlauben, gespeicherte Antworten für einige oder alle Ursprungsserver zu löschen.

7.1 Cache Poisoning (Cache-Vergiftung)

Das Speichern von bösartigem Inhalt in einem Cache kann die Reichweite eines Angreifers vergrößern, um mehrere Benutzer zu beeinflussen. Dieser "Cache-Vergiftung (Cache Poisoning)"-Angriff tritt auf, wenn ein Angreifer Implementierungsfehler, erhöhte Privilegien oder andere Techniken verwendet, um eine Antwort in einen Cache einzufügen. Dies ist besonders effektiv, wenn ein gemeinsam genutzter Cache verwendet wird, um bösartigen Inhalt an viele Clients zu verteilen.

Ein häufiger Vektor für Cache-Vergiftungsangriffe besteht darin, Unterschiede im Message-Parsing zwischen Proxys und User-Agents auszunutzen; siehe Abschnitt 6.3 von [HTTP/1.1] für die relevanten Anforderungen.

7.2 Timing Attacks (Timing-Angriffe)

Da eine der Hauptverwendungen eines Caches die Optimierung der Leistung ist, kann seine Verwendung Informationen darüber "leaken (Leak)", welche Ressourcen zuvor angefordert wurden.

Zum Beispiel, wenn ein Benutzer eine Website besucht und sein Browser einige ihrer Antworten cached, dann zu einer zweiten Website navigiert, kann diese Website versuchen, Antworten zu laden, von denen sie weiß, dass sie auf der ersten Website existieren. Wenn sie schnell laden, kann angenommen werden, dass der Benutzer diese Website oder sogar eine bestimmte Seite darauf besucht hat.

Diese "Timing-Angriffe (Timing Attacks)" können gemildert werden, indem dem Cache-Schlüssel mehr Informationen hinzugefügt werden (zum Beispiel die Identität der verweisenden Website, um den oben beschriebenen Angriff zu verhindern). Dies wird manchmal als "Doppelte Schlüsselung (Double Keying)" bezeichnet.

7.3 Caching of Sensitive Information (Caching sensibler Informationen)

Implementierungs- und Bereitstellungsfehler (oft aufgrund eines Missverständnisses des Cache-Betriebs) können dazu führen, dass sensible Informationen (wie Authentifizierungsdaten) gecached werden, wodurch sie unbefugten Parteien ausgesetzt werden.

Beachten Sie, dass das Set-Cookie-Antwort-Header-Feld [COOKIE] das Caching nicht unterdrückt; eine cachebare Antwort mit einem Set-Cookie-Header-Feld kann (und wird oft) verwendet werden, um nachfolgende Anfragen an den Cache zu erfüllen. Servern, die das Caching dieser Antworten kontrollieren möchten, wird empfohlen, geeignete Cache-Control-Antwort-Header-Felder auszugeben.