mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-request-smuggling/README.md'] to de
This commit is contained in:
Translator
parent
92b1314c82
commit
527106f6c9
@ -15,7 +15,7 @@ Dies ermöglicht es einem Benutzer, **die nächste Anfrage zu ändern, die nach
|
||||
|
||||
**Content-Length**
|
||||
|
||||
> Der Content-Length-Entitätsheader gibt die Größe des Entitätskörpers in Bytes an, die an den Empfänger gesendet werden.
|
||||
> Der Content-Length-Entitätsheader gibt die Größe des Entitätskörpers in Bytes an, die an den Empfänger gesendet wird.
|
||||
|
||||
**Transfer-Encoding: chunked**
|
||||
|
||||
@ -25,14 +25,14 @@ Dies ermöglicht es einem Benutzer, **die nächste Anfrage zu ändern, die nach
|
||||
### 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.\
|
||||
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 interpretiert, als ob sie **vom nächsten Client** stammt und die **echte Anfrage** dieses Clients **Teil** der **injizierten Anfrage** sein wird.
|
||||
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 interpretiert, als ob sie **vom nächsten Client** stammt und die **echte Anfrage** dieses Clients **Teil** der **injizierten Anfrage** sein wird.
|
||||
|
||||
### Besonderheiten
|
||||
|
||||
Denken Sie daran, dass in HTTP **ein neuer Zeilenzeichen aus 2 Bytes besteht:**
|
||||
|
||||
- **Content-Length**: Dieser Header verwendet eine **dezimale Zahl**, um die **Anzahl** der **Bytes** des **Körpers** der Anfrage anzugeben. Der Körper wird erwartet, dass er mit dem letzten Zeichen endet, **ein neuer Zeilenzeichen ist am Ende der Anfrage nicht erforderlich**.
|
||||
- **Transfer-Encoding:** Dieser Header verwendet im **Körper** eine **hexadezimale Zahl**, um die **Anzahl** der **Bytes** des **nächsten Chunks** anzugeben. Der **Chunk** muss mit einem **neuen Zeilenzeichen** **enden**, aber dieses neue Zeilenzeichen **wird nicht** vom Längenindikator gezählt. Diese Übertragungsmethode muss mit einem **Chunk der Größe 0, gefolgt von 2 neuen Zeilen** enden: `0`
|
||||
- **Transfer-Encoding:** Dieser Header verwendet im **Körper** eine **hexadezimale Zahl**, um die **Anzahl** der **Bytes** des **nächsten Chunks** anzugeben. Der **Chunk** muss mit einem **neuen Zeilenzeichen** enden, aber dieses neue Zeilenzeichen **wird nicht** vom Längenindikator gezählt. Diese Übertragungsmethode muss mit einem **Chunk der Größe 0, gefolgt von 2 neuen Zeilen** enden: `0`
|
||||
- **Connection**: Basierend auf meiner Erfahrung wird empfohlen, **`Connection: keep-alive`** in der ersten Anfrage des Request Smuggling zu verwenden.
|
||||
|
||||
## Grundlegende Beispiele
|
||||
@ -56,7 +56,7 @@ HTTP-Request-Smuggling-Angriffe werden durch das Senden von mehrdeutigen Anfrage
|
||||
- **Angriffsszenario:**
|
||||
|
||||
- Der Angreifer sendet eine Anfrage, bei der der Wert des `Content-Length`-Headers nicht mit der tatsächlichen Inhaltslänge übereinstimmt.
|
||||
- Der Front-End-Server leitet die gesamte Anfrage an das Back-End weiter, basierend auf dem Wert von `Content-Length`.
|
||||
- Der Front-End-Server leitet die gesamte Anfrage an das Back-End weiter, basierend auf dem `Content-Length`-Wert.
|
||||
- Der Back-End-Server verarbeitet die Anfrage als chunked aufgrund des `Transfer-Encoding: chunked`-Headers und interpretiert die verbleibenden Daten als separate, nachfolgende Anfrage.
|
||||
- **Beispiel:**
|
||||
|
||||
@ -108,7 +108,7 @@ x=
|
||||
- **Angriffsszenario:**
|
||||
|
||||
- Der Angreifer sendet eine Anfrage mit obfuskierten `Transfer-Encoding`-Headern.
|
||||
- Je nachdem, welcher Server (Front-End oder Back-End) die Obfuskation nicht erkennt, kann eine CL.TE- oder TE.CL-Schwachstelle ausgenutzt werden.
|
||||
- Abhängig davon, welcher Server (Front-End oder Back-End) die Obfuskation nicht erkennt, kann eine CL.TE- oder TE.CL-Schwachstelle ausgenutzt werden.
|
||||
- Der nicht verarbeitete Teil der Anfrage, wie er von einem der Server gesehen wird, wird Teil einer nachfolgenden Anfrage, was zu Smuggling führt.
|
||||
- **Beispiel:**
|
||||
|
||||
@ -132,7 +132,7 @@ Transfer-Encoding
|
||||
#### **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 Interpretation der Anfragenlänge durch beide Server gibt.
|
||||
- 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.
|
||||
- **Beispiel:**
|
||||
|
||||
```
|
||||
@ -263,9 +263,9 @@ X
|
||||
- **Transfer-Encoding Variance Tests:**
|
||||
- Senden Sie Anfragen mit obfuskierten oder fehlerhaften `Transfer-Encoding`-Headern und überwachen Sie, wie unterschiedlich die Front-End- und Back-End-Server auf solche Manipulationen reagieren.
|
||||
|
||||
### HTTP Request Smuggling Schwachstellentest
|
||||
### Testen von HTTP Request Smuggling-Schwachstellen
|
||||
|
||||
Nachdem die Wirksamkeit der 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 eine Anfrage an `/` zu senden, die eine 404-Antwort zurückgibt. Die zuvor besprochenen `CL.TE`- und `TE.CL`-Beispiele in [Basic Examples](#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, indem Sie beispielsweise eine Anfrage an `/` senden, die eine 404-Antwort zurückgibt. Die zuvor besprochenen `CL.TE`- und `TE.CL`-Beispiele in [Basic Examples](#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.
|
||||
|
||||
**Wichtige Überlegungen**
|
||||
|
||||
@ -273,7 +273,7 @@ Beim Testen auf Request Smuggling-Schwachstellen durch Störung anderer Anfragen
|
||||
|
||||
- **Getrennte Netzwerkverbindungen:** Die "Angriffs"- und "normalen" Anfragen sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide validiert nicht das Vorhandensein der Schwachstelle.
|
||||
- **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.
|
||||
- **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. Bei stark frequentierten Anwendungen sind möglicherweise mehrere Versuche erforderlich, 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.
|
||||
|
||||
@ -320,7 +320,7 @@ Content_Length: 47
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Impact: keine. Sie haben lediglich Ihren Client vom Server-Framework desynchronisiert.
|
||||
Impact: keine. Sie haben nur Ihren Client vom Server-Framework desynchronisiert.
|
||||
|
||||
> [!TIP]
|
||||
> Burp-Module, die von Wiederverwendung/Pipelining abhängen: Turbo Intruder mit `requestsPerConnection>1`, Intruder mit "HTTP/1-Verbindungswiederverwendung", Repeater "Gruppe in Reihenfolge senden (einzelne Verbindung)" oder "Verbindungswiederverwendung aktivieren".
|
||||
@ -328,7 +328,7 @@ Impact: keine. Sie haben lediglich Ihren Client vom Server-Framework desynchroni
|
||||
### Litmus-Tests: Pipelining oder echte Desynchronisation?
|
||||
|
||||
1. Wiederverwendung deaktivieren und erneut testen
|
||||
- In Burp Intruder/Repeater, HTTP/1-Wiederverwendung deaktivieren und "Gruppe in Reihenfolge senden" vermeiden.
|
||||
- In Burp Intruder/Repeater, HTTP/1-Wiederverwendung ausschalten und "Gruppe in Reihenfolge senden" vermeiden.
|
||||
- In Turbo Intruder, `requestsPerConnection=1` setzen und `pipeline=False`.
|
||||
- Wenn das Verhalten verschwindet, war es wahrscheinlich clientseitiges Pipelining, es sei denn, Sie haben es mit verbindungsgesperrten/stateful Zielen oder clientseitiger Desynchronisation zu tun.
|
||||
2. HTTP/2-Nested-Response-Check
|
||||
@ -350,9 +350,9 @@ Einige Front-Ends verwenden die upstream-Verbindung nur wieder, wenn der Client
|
||||
- Verwenden Sie Partial-Requests, um zu zeigen, dass das FE nur upstream wiederverwendet, wenn der Client dies tut.
|
||||
- Zeigen Sie echten Einfluss, auch wenn direkter Missbrauch von Benutzer-Sockets blockiert ist:
|
||||
- Cache-Vergiftung: vergiften Sie gemeinsame Caches über die Desynchronisation, sodass Antworten andere Benutzer betreffen.
|
||||
- Offenlegung interner Header: spiegeln Sie FE-injizierte Header (z. B. Auth-/Trust-Header) und pivotieren Sie zu Auth-Bypass.
|
||||
- Offenlegung interner Header: spiegeln Sie FE-injizierte Header (z. B. Auth-/Vertrauensheader) und pivotieren Sie zu Auth-Bypass.
|
||||
- Umgehen von FE-Kontrollen: schmuggeln Sie eingeschränkte Pfade/Methoden am Front-End vorbei.
|
||||
- Missbrauch von Host-Headern: kombinieren Sie dies mit Routing-Eigenheiten von Hosts, um zu internen vhosts zu pivotieren.
|
||||
- Missbrauch von Host-Headern: kombinieren Sie dies mit Routing-Anomalien von Hosts, um zu internen vhosts zu pivotieren.
|
||||
- Operator-Workflow
|
||||
- Reproduzieren Sie mit kontrollierter Wiederverwendung (Turbo Intruder `requestsPerConnection=2` oder Burp Repeater Tab-Gruppe → "Gruppe in Reihenfolge senden (einzelne Verbindung)").
|
||||
- Ketten Sie dann zu Cache-/Header-Leak-/Kontroll-Bypass-Primitiven und demonstrieren Sie den Einfluss auf Benutzer oder Autorisierung.
|
||||
@ -370,7 +370,7 @@ Wenn Sie browsergestützte/clientseitige Desynchronisation anvisieren, muss die
|
||||
Für Hintergrundinformationen und End-to-End-Workflows:
|
||||
|
||||
{{#ref}}
|
||||
-browser-http-request-smuggling.md
|
||||
browser-http-request-smuggling.md
|
||||
{{#endref}}
|
||||
|
||||
### Werkzeuge zur Entscheidungsfindung
|
||||
@ -381,15 +381,15 @@ Für Hintergrundinformationen und End-to-End-Workflows:
|
||||
- Burp HTTP Request Smuggler: enthält eine Verbindungsstatus-Überprüfung, um Routing/Validierung der ersten Anfrage zu erkennen.
|
||||
|
||||
> [!NOTE]
|
||||
> Behandeln Sie nur-Wiederverwendungseffekte als Nicht-Probleme, es sei denn, Sie können serverseitige Desynchronisation nachweisen und konkreten Einfluss anfügen (vergiftetes Cache-Artefakt, offengelegter interner Header, der Privilegienumgehung ermöglicht, umgangene FE-Kontrolle usw.).
|
||||
> Behandeln Sie nur-Wiederverwendungseffekte als Nichtprobleme, es sei denn, Sie können serverseitige Desynchronisation nachweisen und konkreten Einfluss (vergiftetes Cache-Artefakt, offengelegter interner Header, der Privilegienumgehung ermöglicht, umgangene FE-Kontrolle usw.) anhängen.
|
||||
|
||||
## Missbrauch von HTTP Request Smuggling
|
||||
|
||||
### Umgehung der Front-End-Sicherheit über HTTP Request Smuggling
|
||||
|
||||
Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch und überprüfen eingehende Anfragen. 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.
|
||||
Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch und überprüfen eingehende Anfragen. 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 für die Umgehung dieser Einschränkungen lässt.
|
||||
|
||||
Betrachten Sie die folgenden Beispiele, die veranschaulichen, wie HTTP Request Smuggling verwendet werden kann, um Front-End-Sicherheitskontrollen zu umgehen, insbesondere das Ziel `/admin`, das typischerweise vom Front-End-Proxy geschützt wird:
|
||||
Betrachten Sie die folgenden Beispiele, die veranschaulichen, wie HTTP Request Smuggling verwendet werden kann, um Front-End-Sicherheitskontrollen zu umgehen, insbesondere den `/admin`-Pfad, der typischerweise vom Front-End-Proxy geschützt wird:
|
||||
|
||||
**CL.TE Beispiel**
|
||||
```
|
||||
@ -481,7 +481,7 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
|
||||
|
||||
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
||||
```
|
||||
In diesem Szenario ist der **Kommentarparameter** dazu gedacht, die Inhalte im Kommentarbereich eines Beitrags auf einer öffentlich zugänglichen Seite zu speichern. Folglich werden die Inhalte der nachfolgenden Anfrage als Kommentar angezeigt.
|
||||
In diesem Szenario ist der **Kommentarparameter** dazu gedacht, die Inhalte im Kommentarbereich eines Beitrags auf einer öffentlich zugänglichen Seite zu speichern. Folglich erscheinen die Inhalte der nachfolgenden Anfrage als Kommentar.
|
||||
|
||||
Diese Technik hat jedoch Einschränkungen. Im Allgemeinen erfasst sie Daten nur bis zum Parameter-Trennzeichen, das in der geschmuggelten Anfrage verwendet wird. Bei URL-kodierten Formularübertragungen ist dieses Trennzeichen das `&`-Zeichen. Das bedeutet, dass der erfasste Inhalt aus der Anfrage des Opfers beim ersten `&` stoppt, das möglicherweise sogar Teil der Abfragezeichenfolge ist.
|
||||
|
||||
@ -494,7 +494,7 @@ HTTP Request Smuggling kann genutzt werden, um Webseiten auszunutzen, die anfäl
|
||||
- Die Interaktion mit den Zielbenutzern ist **nicht erforderlich**.
|
||||
- Ermöglicht die Ausnutzung von XSS in Teilen der Anfrage, die **normalerweise unerreichbar** sind, wie HTTP-Anforderungsheader.
|
||||
|
||||
In Szenarien, in denen eine Website anfällig für reflektiertes XSS über den User-Agent-Header ist, zeigt die folgende Payload, wie man diese Schwachstelle ausnutzen kann:
|
||||
In Szenarien, in denen eine Website über den User-Agent-Header anfällig für reflektiertes XSS ist, zeigt die folgende Payload, wie man diese Schwachstelle ausnutzen kann:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
|
||||
@ -517,7 +517,7 @@ A=
|
||||
```
|
||||
Dieses Payload ist so strukturiert, dass es die Schwachstelle ausnutzt, indem es:
|
||||
|
||||
1. Eine `POST`-Anfrage initiiert, die scheinbar typisch ist, mit einem `Transfer-Encoding: chunked`-Header, um den Beginn des Smugglings anzuzeigen.
|
||||
1. Eine `POST`-Anfrage initiiert, die scheinbar typisch ist, mit einem `Transfer-Encoding: chunked`-Header, um den Beginn des Smuggelns anzuzeigen.
|
||||
2. Gefolgt von einer `0`, die das Ende des chunked Nachrichtentextes markiert.
|
||||
3. Dann wird eine geschmuggelte `GET`-Anfrage eingeführt, bei der der `User-Agent`-Header mit einem Skript, `<script>alert(1)</script>`, injiziert wird, was die XSS auslöst, wenn der Server diese nachfolgende Anfrage verarbeitet.
|
||||
|
||||
@ -526,13 +526,13 @@ Durch die Manipulation des `User-Agent` durch Smuggling umgeht das Payload die n
|
||||
#### HTTP/0.9
|
||||
|
||||
> [!CAUTION]
|
||||
> Falls der Benutzerinhalt in einer Antwort mit einem **`Content-type`** wie **`text/plain`** widergespiegelt wird, wird die Ausführung der XSS verhindert. Wenn der Server **HTTP/0.9** unterstützt, könnte es möglich sein, dies zu umgehen!
|
||||
> Falls der Benutzerinhalt in einer Antwort mit einem **`Content-type`** wie **`text/plain`** reflektiert wird, wird die Ausführung der XSS verhindert. Wenn der Server **HTTP/0.9** unterstützt, könnte es möglich sein, dies zu umgehen!
|
||||
|
||||
Die Version HTTP/0.9 war zuvor zu 1.0 und verwendet nur **GET**-Verben und **antwortet nicht** mit **Headers**, nur mit dem Body.
|
||||
|
||||
In [**diesem Bericht**](https://mizu.re/post/twisty-python) wurde dies mit einem Request Smuggling und einem **anfälligen Endpunkt, der mit der Eingabe des Benutzers antwortet**, ausgenutzt, um eine Anfrage mit HTTP/0.9 zu schmuggeln. Der Parameter, der in der Antwort widergespiegelt wird, enthielt eine **falsche HTTP/1.1-Antwort (mit Headers und Body)**, sodass die Antwort gültigen ausführbaren JS-Code mit einem `Content-Type` von `text/html` enthält.
|
||||
In [**diesem Bericht**](https://mizu.re/post/twisty-python) wurde dies mit einem Request Smuggling und einem **anfälligen Endpunkt, der mit der Eingabe des Benutzers antwortet**, ausgenutzt, um eine Anfrage mit HTTP/0.9 zu schmuggeln. Der Parameter, der in der Antwort reflektiert wird, enthielt eine **falsche HTTP/1.1-Antwort (mit Headers und Body)**, sodass die Antwort gültigen ausführbaren JS-Code mit einem `Content-Type` von `text/html` enthält.
|
||||
|
||||
### Ausnutzen von On-site-Redirects mit HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
### Ausnutzen von On-Site-Redirects mit HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
Anwendungen leiten oft von einer URL zu einer anderen um, indem sie den Hostnamen aus dem `Host`-Header in der Umleitungs-URL verwenden. Dies ist bei Webservern wie Apache und IIS üblich. Zum Beispiel führt die Anforderung eines Ordners ohne abschließenden Schrägstrich zu einer Umleitung, um den Schrägstrich einzuschließen:
|
||||
```
|
||||
@ -608,8 +608,8 @@ Anschließend wird jede Anfrage für `/static/include.js` den zwischengespeicher
|
||||
|
||||
> **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 anderen Anwendungsbenutzern aus dem Cache bereitgestellt.
|
||||
> - 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.
|
||||
> - Bei **Web-Cache-Poisoning** verursacht der Angreifer, dass die Anwendung einige bösartige 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 einige sensible Inhalte, die einem anderen Benutzer gehören, im Cache speichert, und der Angreifer ruft dann diese Inhalte aus dem Cache ab.
|
||||
|
||||
Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible benutzerspezifische Inhalte abruft. Betrachten Sie das folgende Beispiel:
|
||||
```markdown
|
||||
@ -626,7 +626,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, wenn die Methode TRACE auf dem Server aktiviert ist, es möglich sein könnte, sie mit einem HTTP Request Smuggling auszunutzen. 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 anwendet. 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:
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
@ -693,15 +693,15 @@ Content-Length: 50
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
### Waffeln von HTTP Request Smuggling mit HTTP Response Desynchronisation
|
||||
### Waffensystematisierung von HTTP Request Smuggling mit HTTP Response Desynchronisation
|
||||
|
||||
Haben Sie eine HTTP Request Smuggling-Sicherheitsanfälligkeit gefunden und wissen nicht, wie Sie sie ausnutzen können? Versuchen Sie diese andere Methode der Ausnutzung:
|
||||
Haben Sie eine HTTP Request Smuggling-Schwachstelle gefunden und wissen nicht, wie Sie sie ausnutzen können? Versuchen Sie diese andere Methode der Ausnutzung:
|
||||
|
||||
{{#ref}}
|
||||
../http-response-smuggling-desync.md
|
||||
{{#endref}}
|
||||
|
||||
### Andere HTTP Request Smuggling Techniken
|
||||
### Weitere HTTP Request Smuggling Techniken
|
||||
|
||||
- Browser HTTP Request Smuggling (Client-Seite)
|
||||
|
||||
@ -811,7 +811,7 @@ table.add(req)
|
||||
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
|
||||
- [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
|
||||
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
|
||||
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Dieses Tool ist ein grammatikbasierter HTTP-Fuzzer, der nützlich ist, um seltsame Unterschiede beim Request Smuggling zu finden.
|
||||
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Dieses Tool ist ein grammatikbasiertes HTTP-Fuzzer, das nützlich ist, um seltsame Unterschiede beim Request Smuggling zu finden.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user