# Cache Poisoning und Cache Deception

{{#include ../../banners/hacktricks-training.md}}

## Der Unterschied

> **Was ist der Unterschied zwischen Web-Cache-Poisoning und Web-Cache-Deception?**
>
> - Bei **Web-Cache-Poisoning** verursacht der Angreifer, dass die Anwendung schädliche Inhalte im Cache speichert, und diese Inhalte werden aus dem Cache an andere Anwendungsbenutzer ausgeliefert.
> - Bei **Web-Cache-Deception** verursacht der Angreifer, dass die Anwendung sensible Inhalte eines anderen Benutzers im Cache speichert, und der Angreifer ruft dann diese Inhalte aus dem Cache ab.

## Cache Poisoning

Cache Poisoning zielt darauf ab, den Client-seitigen Cache zu manipulieren, um Clients dazu zu bringen, Ressourcen zu laden, die unerwartet, teilweise oder unter der Kontrolle eines Angreifers stehen. Das Ausmaß der Auswirkungen hängt von der Popularität der betroffenen Seite ab, da die kontaminierte Antwort ausschließlich an Benutzer ausgeliefert wird, die die Seite während der Cache-Kontamination besuchen.

Die Durchführung eines Cache-Poisoning-Angriffs umfasst mehrere Schritte:

1. **Identifizierung von Unkeyed Inputs**: Dies sind Parameter, die, obwohl sie nicht erforderlich sind, damit eine Anfrage im Cache gespeichert wird, die Antwort des Servers ändern können. Die Identifizierung dieser Eingaben ist entscheidend, da sie ausgenutzt werden können, um den Cache zu manipulieren.
2. **Ausnutzung der Unkeyed Inputs**: Nach der Identifizierung der unkeyed Inputs besteht der nächste Schritt darin, herauszufinden, wie diese Parameter missbraucht werden können, um die Antwort des Servers in einer Weise zu ändern, die dem Angreifer zugutekommt.
3. **Sicherstellen, dass die vergiftete Antwort im Cache gespeichert wird**: Der letzte Schritt besteht darin, sicherzustellen, dass die manipulierte Antwort im Cache gespeichert wird. Auf diese Weise erhält jeder Benutzer, der die betroffene Seite besucht, während der Cache vergiftet ist, die kontaminierte Antwort.

### Entdeckung: Überprüfen der HTTP-Header

In der Regel gibt es, wenn eine Antwort **im Cache gespeichert wurde**, einen **Header, der dies anzeigt**. Sie können überprüfen, auf welche Header Sie in diesem Beitrag achten sollten: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

### Entdeckung: Caching-Fehlercodes

Wenn Sie denken, dass die Antwort im Cache gespeichert wird, könnten Sie versuchen, **Anfragen mit einem fehlerhaften Header zu senden**, auf die mit einem **Statuscode 400** geantwortet werden sollte. Versuchen Sie dann, die Anfrage normal zuzugreifen, und wenn die **Antwort ein 400-Statuscode ist**, wissen Sie, dass sie anfällig ist (und Sie könnten sogar einen DoS durchführen).

Weitere Optionen finden Sie in:

{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}

Beachten Sie jedoch, dass **manchmal diese Arten von Statuscodes nicht im Cache gespeichert werden**, sodass dieser Test möglicherweise nicht zuverlässig ist.

### Entdeckung: Identifizieren und Bewerten von Unkeyed Inputs

Sie könnten [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) verwenden, um **Parameter und Header zu brute-forcen**, die möglicherweise **die Antwort der Seite ändern**. Zum Beispiel könnte eine Seite den Header `X-Forwarded-For` verwenden, um dem Client anzuzeigen, dass das Skript von dort geladen werden soll:
```markup
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Elicit a harmful response from the back-end server

Mit dem identifizierten Parameter/Kopfzeile überprüfen, wie er **bereinigt** wird und **wo** er **reflektiert** wird oder die Antwort aus der Kopfzeile beeinflusst. Kannst du es irgendwie missbrauchen (eine XSS durchführen oder einen von dir kontrollierten JS-Code laden? einen DoS durchführen?...)

### Get the response cached

Sobald du die **Seite** identifiziert hast, die missbraucht werden kann, welchen **Parameter**/**Kopfzeile** du verwenden und **wie** du ihn **missbrauchen** kannst, musst du die Seite im Cache speichern. Je nach Ressource, die du im Cache speichern möchtest, kann dies einige Zeit in Anspruch nehmen, du musst möglicherweise mehrere Sekunden lang versuchen.

Die Kopfzeile **`X-Cache`** in der Antwort könnte sehr nützlich sein, da sie den Wert **`miss`** haben kann, wenn die Anfrage nicht im Cache gespeichert wurde, und den Wert **`hit`**, wenn sie im Cache gespeichert ist.\
Die Kopfzeile **`Cache-Control`** ist ebenfalls interessant, um zu wissen, ob eine Ressource im Cache gespeichert wird und wann die Ressource das nächste Mal wieder im Cache gespeichert wird: `Cache-Control: public, max-age=1800`

Eine weitere interessante Kopfzeile ist **`Vary`**. Diese Kopfzeile wird häufig verwendet, um **zusätzliche Kopfzeilen** anzugeben, die als **Teil des Cache-Schlüssels** behandelt werden, auch wenn sie normalerweise nicht als Schlüssel verwendet werden. Daher kann der Benutzer, wenn er den `User-Agent` des Opfers kennt, das er anvisiert, den Cache für die Benutzer mit diesem spezifischen `User-Agent` vergiften.

Eine weitere Kopfzeile, die mit dem Cache zusammenhängt, ist **`Age`**. Sie definiert die Zeit in Sekunden, die das Objekt im Proxy-Cache war.

Beim Caching einer Anfrage sei **vorsichtig mit den Kopfzeilen, die du verwendest**, da einige von ihnen **unerwartet** als **schlüsselig** verwendet werden könnten und das **Opfer diese gleiche Kopfzeile verwenden muss**. Teste immer eine Cache-Vergiftung mit **verschiedenen Browsern**, um zu überprüfen, ob es funktioniert.

## Exploiting Examples

### Easiest example

Eine Kopfzeile wie `X-Forwarded-For` wird unsaniert in der Antwort reflektiert.\
Du kannst eine grundlegende XSS-Nutzlast senden und den Cache vergiften, sodass jeder, der auf die Seite zugreift, XSS ausgesetzt wird:
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Beachten Sie, dass dies eine Anfrage an `/en?region=uk` und nicht an `/en` vergiften wird._

### Cache-Vergiftung für DoS

{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}

### Verwendung von Web-Cache-Vergiftung zur Ausnutzung von Cookie-Verwundbarkeiten

Cookies könnten auch in der Antwort einer Seite reflektiert werden. Wenn Sie dies missbrauchen können, um beispielsweise ein XSS zu verursachen, könnten Sie in der Lage sein, XSS in mehreren Clients auszunutzen, die die bösartige Cache-Antwort laden.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Beachten Sie, dass, wenn das verwundbare Cookie von den Benutzern häufig verwendet wird, regelmäßige Anfragen den Cache bereinigen.

### Generierung von Abweichungen mit Trennzeichen, Normalisierung und Punkten <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Überprüfen Sie:

{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}

### Cache-Poisoning mit Pfadüberquerung zum Stehlen des API-Schlüssels <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

[**Dieser Bericht erklärt**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html), wie es möglich war, einen OpenAI API-Schlüssel mit einer URL wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` zu stehlen, da alles, was mit `/share/*` übereinstimmt, ohne dass Cloudflare die URL normalisiert, im Cache gespeichert wird, was geschah, als die Anfrage den Webserver erreichte.

Dies wird auch besser erklärt in:

{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}

### Verwendung mehrerer Header zur Ausnutzung von Web-Cache-Poisoning-Schwachstellen <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Manchmal müssen Sie **mehrere unverschlüsselte Eingaben ausnutzen**, um einen Cache zu missbrauchen. Zum Beispiel können Sie einen **Open Redirect** finden, wenn Sie `X-Forwarded-Host` auf eine von Ihnen kontrollierte Domain und `X-Forwarded-Scheme` auf `http` setzen. **Wenn** der **Server** alle **HTTP**-Anfragen **an HTTPS** weiterleitet und den Header `X-Forwarded-Scheme` als Domainnamen für die Weiterleitung verwendet. Sie können steuern, wohin die Seite durch die Weiterleitung zeigt.
```markup
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
```
### Ausnutzen des begrenzten `Vary`-Headers

Wenn Sie festgestellt haben, dass der **`X-Host`**-Header als **Domainname zum Laden einer JS-Ressource** verwendet wird, der **`Vary`**-Header in der Antwort jedoch **`User-Agent`** angibt, müssen Sie einen Weg finden, den User-Agent des Opfers zu exfiltrieren und den Cache mit diesem User-Agent zu vergiften:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Fat Get

Senden Sie eine GET-Anfrage mit der Anfrage in der URL und im Body. Wenn der Webserver den aus dem Body verwendet, der Cache-Server jedoch den aus der URL cached, wird jeder, der auf diese URL zugreift, tatsächlich den Parameter aus dem Body verwenden. Wie die Schwachstelle, die James Kettle auf der Github-Website gefunden hat:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim
```
Es gibt ein Portswigger-Labor dazu: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

### Parameter Cloaking

Zum Beispiel ist es möglich, **Parameter** in Ruby-Servern mit dem Zeichen **`;`** anstelle von **`&`** zu trennen. Dies könnte verwendet werden, um unverschlüsselte Parameterwerte in verschlüsselte einzufügen und sie auszunutzen.

Portswigger-Labor: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)

### Ausnutzen von HTTP-Cache-Poisoning durch Missbrauch von HTTP Request Smuggling

Erfahren Sie hier, wie man [Cache-Poisoning-Angriffe durch Missbrauch von HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning) durchführt.

### Automatisierte Tests für Web-Cache-Poisoning

Der [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kann verwendet werden, um automatisch nach Web-Cache-Poisoning zu testen. Er unterstützt viele verschiedene Techniken und ist hochgradig anpassbar.

Beispielverwendung: `wcvs -u example.com`

## Verwundbare Beispiele

### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

ATS leitete den Fragmentteil innerhalb der URL weiter, ohne ihn zu entfernen, und generierte den Cache-Schlüssel nur unter Verwendung des Hosts, des Pfads und der Abfrage (das Fragment ignorierend). Daher wurde die Anfrage `/#/../?r=javascript:alert(1)` an das Backend als `/#/../?r=javascript:alert(1)` gesendet, und der Cache-Schlüssel enthielt nicht die Payload, nur Host, Pfad und Abfrage.

### GitHub CP-DoS

Das Senden eines fehlerhaften Wertes im Content-Type-Header löste eine 405-Cache-Antwort aus. Der Cache-Schlüssel enthielt das Cookie, sodass es nur möglich war, nicht authentifizierte Benutzer anzugreifen.

### GitLab + GCP CP-DoS

GitLab verwendet GCP-Buckets zur Speicherung statischer Inhalte. **GCP-Buckets** unterstützen den **Header `x-http-method-override`**. Daher war es möglich, den Header `x-http-method-override: HEAD` zu senden und den Cache so zu vergiften, dass er einen leeren Antwortkörper zurückgibt. Es könnte auch die Methode `PURGE` unterstützen.

### Rack Middleware (Ruby on Rails)

In Ruby on Rails-Anwendungen wird häufig Rack-Middleware verwendet. Der Zweck des Rack-Codes besteht darin, den Wert des **`x-forwarded-scheme`**-Headers zu übernehmen und ihn als Schema der Anfrage festzulegen. Wenn der Header `x-forwarded-scheme: http` gesendet wird, erfolgt eine 301-Weiterleitung an denselben Ort, was möglicherweise zu einer Denial of Service (DoS) für diese Ressource führt. Darüber hinaus könnte die Anwendung den `X-forwarded-host`-Header anerkennen und Benutzer an den angegebenen Host umleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien von einem Server des Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.

### 403 und Speicher-Buckets

Cloudflare hat zuvor 403-Antworten zwischengespeichert. Der Versuch, auf S3 oder Azure Storage Blobs mit falschen Autorisierungs-Headern zuzugreifen, führte zu einer 403-Antwort, die zwischengespeichert wurde. Obwohl Cloudflare das Zwischenspeichern von 403-Antworten eingestellt hat, könnte dieses Verhalten weiterhin in anderen Proxy-Diensten vorhanden sein.

### Einspeisen von verschlüsselten Parametern

Caches enthalten häufig spezifische GET-Parameter im Cache-Schlüssel. Zum Beispiel speicherte Varnish von Fastly den `size`-Parameter in Anfragen. Wenn jedoch eine URL-kodierte Version des Parameters (z.B. `siz%65`) ebenfalls mit einem fehlerhaften Wert gesendet wurde, wurde der Cache-Schlüssel unter Verwendung des korrekten `size`-Parameters erstellt. Das Backend würde jedoch den Wert im URL-kodierten Parameter verarbeiten. Die URL-Kodierung des zweiten `size`-Parameters führte zu dessen Auslassung durch den Cache, aber zu seiner Nutzung durch das Backend. Das Zuweisen eines Wertes von 0 zu diesem Parameter führte zu einem cachebaren 400 Bad Request-Fehler.

### Benutzer-Agent-Regeln

Einige Entwickler blockieren Anfragen mit Benutzer-Agenten, die mit denen von stark frequentierten Tools wie FFUF oder Nuclei übereinstimmen, um die Serverlast zu steuern. Ironischerweise kann dieser Ansatz Schwachstellen wie Cache-Poisoning und DoS einführen.

### Ungültige Header-Felder

Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spezifiziert die akzeptablen Zeichen in Headernamen. Header, die Zeichen außerhalb des angegebenen **tchar**-Bereichs enthalten, sollten idealerweise eine 400 Bad Request-Antwort auslösen. In der Praxis halten sich Server jedoch nicht immer an diesen Standard. Ein bemerkenswertes Beispiel ist Akamai, das Header mit ungültigen Zeichen weiterleitet und jeden 400-Fehler zwischenspeichert, solange der `cache-control`-Header nicht vorhanden ist. Ein ausnutzbares Muster wurde identifiziert, bei dem das Senden eines Headers mit einem ungültigen Zeichen, wie `\`, zu einem cachebaren 400 Bad Request-Fehler führte.

### Finden neuer Header

[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

## Cache-Deception

Das Ziel von Cache-Deception ist es, dass Clients **Ressourcen laden, die mit ihren sensiblen Informationen vom Cache gespeichert werden**.

Zunächst einmal beachten Sie, dass **Erweiterungen** wie `.css`, `.js`, `.png` usw. normalerweise **konfiguriert** sind, um im **Cache** **gespeichert** zu werden. Daher, wenn Sie `www.example.com/profile.php/nonexistent.js` aufrufen, wird der Cache wahrscheinlich die Antwort speichern, da er die `.js` **Erweiterung** sieht. Wenn jedoch die **Anwendung** mit den **sensiblen** Benutzerinhalten, die in _www.example.com/profile.php_ gespeichert sind, **antwortet**, können Sie diese Inhalte von anderen Benutzern **stehlen**.

Weitere Dinge, die getestet werden sollten:

- _www.example.com/profile.php/.js_
- _www.example.com/profile.php/.css_
- _www.example.com/profile.php/test.js_
- _www.example.com/profile.php/../test.js_
- _www.example.com/profile.php/%2e%2e/test.js_
- _Verwenden Sie weniger bekannte Erweiterungen wie_ `.avif`

Ein weiteres sehr klares Beispiel finden Sie in diesem Bericht: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
In dem Beispiel wird erklärt, dass, wenn Sie eine nicht vorhandene Seite wie _http://www.example.com/home.php/non-existent.css_ laden, der Inhalt von _http://www.example.com/home.php_ (**mit den sensiblen Informationen des Benutzers**) zurückgegeben wird und der Cache-Server das Ergebnis speichern wird.\
Dann kann der **Angreifer** _http://www.example.com/home.php/non-existent.css_ in seinem eigenen Browser aufrufen und die **vertraulichen Informationen** der Benutzer beobachten, die zuvor darauf zugegriffen haben.

Beachten Sie, dass der **Cache-Proxy** so **konfiguriert** sein sollte, dass er Dateien **basierend** auf der **Erweiterung** der Datei (_ .css_) und nicht basierend auf dem Content-Type speichert. Im Beispiel _http://www.example.com/home.php/non-existent.css_ wird ein `text/html`-Content-Type anstelle eines `text/css`-Mime-Typs (der für eine _.css_-Datei erwartet wird) haben.

Erfahren Sie hier, wie man [Cache-Deception-Angriffe durch Missbrauch von HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception) durchführt.

## Automatische Werkzeuge

- [**toxicache**](https://github.com/xhzeem/toxicache): Golang-Scanner, um Web-Cache-Poisoning-Schwachstellen in einer Liste von URLs zu finden und mehrere Injektionstechniken zu testen.

## Referenzen

- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
- [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)


{{#include ../../banners/hacktricks-training.md}}