Bei Web Cache Poisoning handelt es sich um einen Angriff auf den eingesetzten Cache des Webservers oder der Webapplikation, wobei deren Verhalten manipuliert und so fremde Besucher der Webseite angegriffen werden können. Web Cache Poisoning gilt als fortgeschrittene Technik und besteht im Wesentlichen aus der Suche nach einer geeigneten Eingabe, welche vom Server reflektiert wird sowie einem funktionierenden Payload.

Es gibt eine Vielzahl von verschiedenen Cache-Arten, die meisten von ihnen verfolgen aber die gleichen Hauptziele – weniger Netzwerkverkehr, damit auch kürzere Antwortzeit und geringere Auslastung des Webservers. Die Caches befinden sich zwischen Benutzer und Webseite. In einem Cache werden Anfragen auf Ressourcen und deren Antwort, beziehungsweise eine Kopie der Ressourcen (Bilder, Texte und weitere Komponenten) gespeichert für eine festgelegte Zeit.

Unterschiedliche Caches

Der Browser-Cache befindet sich lokal auf dem Computer des Benutzers, genauer gesagt in dessen Browser. Somit hat ein anderer Browser auf dem gleichen Computer keinen Zugriff auf die gespeicherten Inhalte des ersten Browser-Caches. Der Browser-Cache gehört zu den sogenannten privaten Caches, da Drittpersonen keinen Zugriff darauf haben.

Proxy-Server können ebenfalls über einen Cache verfügen, dieser ist jedoch nicht an den Benutzer gebunden, sondern darauf können alle Verbindungen zugreifen, welche über den gleichen Proxy-Server gehen. Dies müssen aber nicht zwingend alle Besucher der Webseite X sein.

Zudem kann der Webserver eigene Caching-Mechanismen besitzen zum Beispiel über ein eingesetztes Framework wie Drupal oder das verwendete Content Delivery Network (CDN) verwendet ein eigenes Caching. Teilweise kommen auch spezifische Produkte wie Varnish zum Einsatz.

Es gibt noch weitere Arten von Caches, jedoch liegt der Fokus in diesem Artikel auf Caching-Mechanismen, welche von allen Webseitenbesucher benutzt werden, sogenannte shared Caches.

Cache-Control Header

Der Cache-Control Header ist ein HTTP-Header, welcher in Requests und Responses verwendet werden kann, um das Caching zu steuern. Durch diesen Header wird festgelegt, ob, wer und wie lange ein Request beziehungsweise eine Response gecacht werden darf. Mit wer sind verschiedene Cache-Parteien wie der Browser, ein Proxy-Server, CDNs sowie weitere gemeint.

Mit max-age kann die maximale Cache-Dauer in Sekunden festgelegt werden Cache-Control: max-age=604800. Die Cache-Dauer startet ab dem Zeitpunkt, wo die Response vom Server generiert wurde.

Requests oder Responses, welche sensitiven Inhalt enthalten sollten aus sicherheitstechnischen Gründen nicht gecacht werden, dafür sollte Cache-Conrol: no-store verwendet werden.

Weitere Informationen zum Cache-Control-Header finden sich in der Dokumentation von Mozilla.

Cache-Keys

Damit der Cache nicht den kompletten Request mit den aktuell gespeicherten Request abgleichen muss, werden sogenannte Cache-Keys eingesetzt. Cache-Keys bestehen normalerweise aus dem HTTP Query und dem Hostname, dies kann jedoch auch anders konfiguriert werden. Bei einer Übereinstimmung wird die gespeicherte Kopie der Response direkt an den Request-Steller übermittelt. Dies geschieht so lange wie die gecachete Ressource gültig ist. Möglicher Cache-Key dieses Artikels: "/?labs.20220512" + "www.scip.ch"

Unkeyed

Komponenten des Requests, welche nicht Teil des Cache-Keys sind, werden als Unkeyed Inputs bezeichnet. Unkeyed Inputs können Request-Headers, Cookies, in seltenen Fällen auch Teile des Query-Strings oder Teile des Request-Bodys (Fat GET-Requests) sein. Diese unkeyed Inputs können zu Problemen führen, beziehungsweise eine Web Cache Poisoning Schwachstelle ermöglichen.

Web Cache Poisoning Beispiel

Beim folgenden Beispiel wird der X-Forwarded-Host Header verwendet, um eine Open Graph URL innerhalb eines meta-Tags zu generieren. In diesem Fall könnte durch das Ändern des X-Forwarded-Host Headers die Domain bestimmt werden und ein anderes Bild geladen werden. Da dies gecacht wird, erhalten alle anderen Besucher mit demselben Querystring innerhalb des Gültigkeitszeitraums des Cachs auch dieses Bild.

GET /de?param=test HTTP/1.1
Host: www.example.com
X-Forwarded-Host: evil

HTTP/1.1 200 OK
...
<meta property="og:image" content="https://evil/images/cat.png" />

Statt einer Domain kann auch JavaScript eingebettet werden, was zu einem Cross-Site-Scripting Angriff führt:

GET /de?param=test2 HTTP/1.1
Host: www.example.com
X-Forwarded-Host: a."><script>alert(1)</script>

HTTP/1.1 200 OK
...
<meta property="og:image" content="https://a."><script>alert(1)</script>" />

Die Beispiele sind inspiriert vom Paper Practical Web Cache Poisoning, in welchem viele verschiedene Arten von Web Cache Poisoning Attacken geschildert werden. Web Cache Poisoning Payloads können auch Open-Redirects oder DOM-XSS Attacken sowie weitere Angriffe umfassen.

Schritte zu einer Web Cache Poisoning Schwachstellen

Zuerst beginnt man mit der Suche nach unkeyed Inputs und was deren Auswirkung sind, also wie sie in der Server Response zurückgegeben werden. Diese Evaluierung kann entweder manuell mit bekannten Request-Headern und anderen häufig betroffenen unkeyed Inputs gemacht werden oder mit der Hilfe von Param Miner, einem Open Source Burp Plugin, welches die Suche nach einem unkeyed Input stark vereinfacht.

Wenn ein vielversprechender unkeyed Input gefunden wurde, beginnt man mit der Suche nach einem Payload, welcher funktionsfähig vom Webserver retourniert wird in der dazugehörigen Response.

Nach der Bestimmung des Payloads wird in einem letzten Schritt die Response mit dem reflektierten Payload so gecacht, dass sie an die gewünschten Drittbesucher via dem eingesetzten Cache ausgeliefert wird.

Beim Testen einer Applikation auf eine Web Cache Poisoning Schwachstelle sollte unbedingt ein Cache Buster verwendet werden. Dies ist ein zufälliger URL-Parameter, welcher verhindert, dass normale Benutzer vom Testen beeinflusst werden. www.example.com/en?RandomCacheBuster=123

Gegenmassnahmen

Die einfachste und gleichzeitig Einschneidendste Gegenmassnahme ist komplett auf Caching zu verzichten. Dies funktioniert bei kleinen Webseiten, welche wenig Netzwerkverkehr und einen Webserver mit genügend Leistung besitzen. Hierbei kann es sein, dass Web-Frameworks eingesetzt werden, welche per Default ein Caching mitbringen, da es jedoch nicht benötigt wird, kann es deaktiviert werden und somit kann die Angriffsfläche verkleinert werden.

Falls nicht komplett auf Caching verzichtet werden kann, sollten ausschliesslich statische Ressourcen gecacht werden. Somit wird Web Cache Poisoning verhindert, da bei Requests auf statische Ressourcen keine Benutzereingaben verarbeiten werden, sind sie auch nicht anfällig für Web Cache Poisoning Attacken.

Wenn das Caching von statischen Inhalten nicht ausreichend ist, kann man es auf dynamische Inhalte ausweiten, sollte aber Input aus Request-Headern oder Cookies nicht verarbeiten beziehungsweise unkeyed Inputs nicht in der Response reflektieren. Hier gilt zu beachten, dass Frameworks teilweise eigene Request-Header mitbringen, welche ebenfalls anfällig sein könnten. Hier kann die Möglichkeit für Web Cache Poisoning aufgrund eines Konfigurationsfehlers nicht ausgeschlossen werden.

Es gibt auch die Möglichkeit unkeyed Request-Headers in den Cache-Key miteinzuschliessen, damit wird der Cache-Key zwar länger. Dadurch, dass der Cache-Key nun zusätzliche Komponenten enthält, kann es vereinzelt mehrere Einträge im Cache geben, jedoch wird die Möglichkeit auf eine erfolgreiche Web Cache Poisoning Attacke reduziert. Dabei sollte der Inhalt von Request-Header nicht verwendet werden, wenn dieser nicht Teil des Cache-Keys ist. Zudem sollten HTTP-Header niemals direkt an Benutzer returniert werden bei gecachten Ressourcen.

Auf GET-Requests mit Body (Fat GET), welche Änderungen an der Server-Response zur Folge haben, sollte verzichtet werden.

Eine zusätzliche Sicherheitsmassnahme wäre die Webapplikation mittels des Einsatzes des Burp Plugins Param Miner zu testen und festgestellte HTTP-Header oder andere unkeyed Inputs genauer zu prüfen.

Fazit

Web Cache Poisoning galt lange als theoretischer Angriff, jedoch zeigte sich auf Bug Bounty Plattformen, dass diese Kombination von einem Cache-Angriff und einer weiteren Schwachstelle heute durchaus auch praktischer Natur ist. Daher sollten Cache-Konfigurationen gut durchdacht und nicht auf der Standardkonfiguration belassen werden. Mit dem Framework mitgelieferte Cache-Mechanismen sollten deaktiviert werden, wenn der Bedarf von Caching nicht vorhanden ist. Falls Sie gerne selber mal eine Web Cache Poisoning Schwachstelle in einer Trainingsumgebung finden möchten, empfehlen wir Portswigger Labs.

Über den Autor

Ralph Meier hat eine Lehre als Applikationsentwickler, Fokus Webentwicklung mit Java, bei einer Schweizer Grossbank absolviert und danach einen Bachelor of Science ZFH in Informatik an der ZHAW School of Engineering abgeschlossen. Er fokussiert sich auf die sicherheitstechnische Untersuchung von Webapplikationen. (ORCID 0000-0002-3997-8482)

Links

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
• https://github.com/PortSwigger/param-miner
• https://portswigger.net/research/practical-web-cache-poisoning
• https://portswigger.net/web-security/all-labs#web-cache-poisoning