Was ist Web Cache Poisoning?

Web Cache Poisoning bringt einen Cache dazu, eine vom Angreifer beeinflusste Antwort zu speichern und später an andere Nutzer auszuliefern. Ursache ist meist ein Unterschied zwischen den Request-Bestandteilen, die die Anwendung zur Antworterzeugung verwendet, und den Bestandteilen, aus denen CDN oder Proxy den Cache-Key bildet.

Wie funktioniert ein Webcache?

Ein Cache speichert eine Antwort unter einem Schlüssel, typischerweise aus Host, Pfad und ausgewählten Query-Parametern. Eine spätere passende Anfrage erhält die gespeicherte Antwort, ohne das Backend erneut aufzurufen. Cache-Control, Vary, Statuscode, Cookies und CDN-Regeln beeinflussen, ob und wie lange gespeichert wird. Header wie Age, anbieterspezifische Cache-Statuswerte und wiederholte identische Antworten geben Hinweise, sind aber nicht überall gleich.

Wie entsteht Cache Poisoning?

1. Der Angreifer findet eine unkeyed input: eine Eingabe, welche die Anwendung verarbeitet, die der Cache aber nicht in seinen Schlüssel aufnimmt.
2. Er sendet eine Anfrage, durch die diese Eingabe in Redirect, Link, Scriptquelle, Fehler oder anderen Antwortinhalt gelangt.
3. Der Cache betrachtet die Antwort als speicherbar und legt sie unter einem gewöhnlichen öffentlichen Schlüssel ab.
4. Weitere Nutzer mit passender URL erhalten den manipulierten Inhalt bis Ablauf, Verdrängung oder Purge.

Eine reflektierte Eingabe allein ist noch kein Cache Poisoning. Sie muss eine sicherheitsrelevante Antwort verändern, und genau diese Antwort muss für andere Anfragen wiederverwendet werden.

Welche Eingaben werden häufig übersehen?

Welche Folgen sind möglich?

Gespeicherte Antworten können auf Phishing- oder Malware-Domains weiterleiten, schädliches JavaScript laden oder Cross-Site Scripting an viele Besucher verteilen. Auch manipulierte Preise, Sicherheitsheader, API-Antworten und lang anhaltende Fehlerseiten sind möglich. Wird eine personalisierte oder authentifizierte Antwort öffentlich gespeichert, kann sie Daten eines Nutzers an andere offenlegen. Reichweite und Cache-Dauer machen eine einzelne Anfrage potenziell folgenreicher als eine gewöhnliche reflektierte Schwachstelle.

Wie wird Cache Poisoning verhindert?

1. Alle legitimen Antwortvarianten in einen konsistenten, normalisierten Cache-Key aufnehmen oder die betreffende Antwort nicht cachen.
2. Unbekannte Host- und Forwarded-Header ablehnen und öffentliche Basis-URLs fest konfigurieren.
3. Personalisierte, authentifizierte, fehlerhafte und zustandsändernde Antworten mit geeigneten Cache-Direktiven schützen.
4. Eingaben kontextgerecht validieren und ausgeben; der Cache darf nicht die einzige XSS- oder Redirect-Abwehr sein.
5. CDN, Proxy und Anwendung bei Methoden, Dekodierung, Query-Handling und Pfadnormalisierung angleichen.
6. Cache-Regeln wie Code versionieren, testen und Purge-Prozesse vorbereiten.

Codebeispiel: Unkeyed Header nicht in öffentliche Antworten übernehmen

Verwundbar: Der Cache-Key besteht nur aus der URL, die Antwort hängt aber von einem weiteren Header ab.

$assetHost = $request->header('X-Forwarded-Host');

return response("<script src=\"https://{$assetHost}/app.js\"></script>")
    ->header('Cache-Control', 'public, max-age=600');

Sicherer:

$assetHost = config('app.asset_host');

return response(view('page', ['assetHost' => $assetHost]))
    ->header('Cache-Control', 'public, max-age=600');

Wird eine legitime Antwort tatsächlich durch Sprache, Kodierung oder einen anderen Header variiert, muss der Cache diese Dimension kontrolliert in seinen Key aufnehmen. Bei nutzerspezifischen Antworten ist öffentliches Caching meist vollständig zu vermeiden.

Wie wird sicher getestet und reagiert?

Tests beginnen mit einem eindeutigen Cache-Buster, einem harmlosen Marker und eigenen Anfragen. Erst wird nachgewiesen, dass die Antwort gecacht wird; anschließend, ob eine nicht im Key enthaltene Eingabe dieselbe Antwort verändert. Das Vergiften einer populären Produktions-URL kann echte Besucher gefährden und braucht eine ausdrückliche Freigabe sowie sofortige Purge-Möglichkeit. Im Vorfall werden betroffene Keys und Varianten gelöscht, Ursache an Anwendung und CDN behoben, Logs auf Reichweite geprüft und gegebenenfalls Browser- oder Client-Caches berücksichtigt.