Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

src/pentesting-web/http-request-smuggling/README.md

@@ -4,8 +4,8 @@
 
 ## 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 (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, die beim Back-End-Server nach seiner eintrifft, 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 (Lastenausgleich/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
 
@@ -15,7 +15,7 @@ Dies ermöglicht es einem Benutzer, **die nächste Anfrage, die beim Back-End-Se
 
 **Content-Length**
 
-> Der Content-Length-Entitätsheader gibt die Größe des Entitätskörpers in Bytes an, die an den Empfänger gesendet wird.
+> Der Content-Length-Entitätsheader gibt die Größe des Entitätskörpers in Bytes an, die an den Empfänger gesendet werden.
 
 **Transfer-Encoding: chunked**
 
@@ -24,30 +24,30 @@ Dies ermöglicht es einem Benutzer, **die nächste Anfrage, die beim Back-End-Se
 
 ### Realität
 
-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 provoziert.\
-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.
+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.
 
 ### Besonderheiten
 
-Denken Sie daran, dass in HTTP **ein Zeilenumbruchzeichen aus 2 Bytes besteht:**
+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 im letzten Zeichen endet, **ein Zeilenumbruch 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 **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.
+- **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`
+- **Connection**: Basierend auf meiner Erfahrung wird empfohlen, **`Connection: keep-alive`** in der ersten Anfrage des Request Smuggling zu verwenden.
 
 ## Grundlegende Beispiele
 
 > [!TIP]
-> 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 ausnutzen.
+> Wenn Sie versuchen, dies mit Burp Suite auszunutzen, **deaktivieren Sie `Update Content-Length` und `Normalize HTTP/1 line endings`** im Repeater, da einige Gadgets mit neuen Zeilen, Wagenrückläufen und fehlerhaften Content-Lengths missbrauchen.
 
 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 Schwachstellentypen
+### Grundlegende Beispiele für Schwachstelltypen
 
 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
 
-> [!NOTE]
-> Zur vorherigen Tabelle sollten Sie die TE.0-Technik hinzufügen, wie die CL.0-Technik, aber unter Verwendung von Transfer-Encoding.
+> [!TIP]
+> Zu der vorherigen Tabelle sollten Sie die TE.0-Technik hinzufügen, wie die CL.0-Technik, aber unter Verwendung von Transfer-Encoding.
 
 #### CL.TE-Schwachstelle (Content-Length wird vom Front-End verwendet, Transfer-Encoding wird vom Back-End verwendet)
 
@@ -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 `Content-Length`-Wert.
+- Der Front-End-Server leitet die gesamte Anfrage an das Back-End weiter, basierend auf dem Wert von `Content-Length`.
 - 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:**
 
@@ -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 Art und Weise gibt, wie beide Server die Anfragelänge interpretieren.
+- Dieses Szenario führt typischerweise nicht zu Smuggling, da es eine Übereinstimmung in der Interpretation der Anfragenlänge durch beide Server gibt.
 - **Beispiel:**
 
 ```
@@ -163,7 +163,7 @@ Nicht leerer Körper
 
 - 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:**
+- **Beispiel**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@@ -183,17 +183,17 @@ 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 die **nächste HTTP-Anfrage** betrachtet.
+Diese Technik ist auch in Szenarien nützlich, 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.
 
-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** lassen. Wenn die HTTP-Verbindung jedoch mit dem Header **`Connection: keep-alive`** erstellt wurde, wird der Body der Anfrage nicht gelesen und die Verbindung bleibt weiterhin offen, sodass der **Body** der Anfrage als die **nächste HTTP-Anfrage** behandelt wird.
+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 weiterhin offen, sodass der **Body** der Anfrage als die **nächste HTTP-Anfrage** behandelt wird.
 
 #### Erzwingen über Hop-by-Hop-Header
 
-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**.
+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
 ```
-Für **weitere Informationen zu hop-by-hop-Headers** besuchen Sie:
+Für **weitere Informationen zu hop-by-hop-Headern** besuchen Sie:
 
 {{#ref}}
 ../abusing-hop-by-hop-headers.md
@@ -207,7 +207,7 @@ Die Identifizierung von HTTP Request Smuggling-Schwachstellen kann oft durch Tim
 
 - **Methode:**
 
-- Senden Sie eine Anfrage, die, falls die Anwendung anfällig ist, den Backend-Server dazu bringt, auf zusätzliche Daten zu warten.
+- Senden Sie eine Anfrage, die, falls die Anwendung anfällig ist, den Back-End-Server dazu bringt, auf zusätzliche Daten zu warten.
 - **Beispiel:**
 
 ```
@@ -224,17 +224,17 @@ A
 
 - **Beobachtung:**
 - Der Front-End-Server verarbeitet die Anfrage basierend auf `Content-Length` und schneidet die Nachricht vorzeitig ab.
-- Der Backend-Server, der eine chunked Nachricht erwartet, wartet auf den nächsten Chunk, der nie ankommt, was zu einer Verzögerung führt.
+- Der Back-End-Server, der eine chunked Nachricht erwartet, wartet auf den nächsten Chunk, der nie ankommt, was zu einer Verzögerung führt.
 
 - **Indikatoren:**
 - Timeouts oder lange Verzögerungen bei der Antwort.
-- Erhalt eines 400 Bad Request-Fehlers vom Backend-Server, manchmal mit detaillierten Serverinformationen.
+- Erhalt eines 400 Bad Request-Fehlers vom Back-End-Server, manchmal mit detaillierten Serverinformationen.
 
 ### Finden von TE.CL-Schwachstellen mit Timing-Techniken
 
 - **Methode:**
 
-- Senden Sie eine Anfrage, die, falls die Anwendung anfällig ist, den Backend-Server dazu bringt, auf zusätzliche Daten zu warten.
+- Senden Sie eine Anfrage, die, falls die Anwendung anfällig ist, den Back-End-Server dazu bringt, auf zusätzliche Daten zu warten.
 - **Beispiel:**
 
 ```
@@ -250,7 +250,7 @@ X
 
 - **Beobachtung:**
 - Der Front-End-Server verarbeitet die Anfrage basierend auf `Transfer-Encoding` und leitet die gesamte Nachricht weiter.
-- Der Backend-Server, der eine Nachricht basierend auf `Content-Length` erwartet, wartet auf zusätzliche Daten, die nie ankommen, was zu einer Verzögerung führt.
+- Der Back-End-Server, der eine Nachricht basierend auf `Content-Length` erwartet, wartet auf zusätzliche Daten, die nie ankommen, was zu einer Verzögerung führt.
 
 ### Andere Methoden zur Auffindung von Schwachstellen
 
@@ -261,29 +261,135 @@ X
 - **Content-Length Variance Tests:**
 - Senden Sie Anfragen mit variierenden `Content-Length`-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachten Sie, wie der Server mit solchen Abweichungen umgeht.
 - **Transfer-Encoding Variance Tests:**
-- Senden Sie Anfragen mit obfuskierten oder fehlerhaften `Transfer-Encoding`-Headern und überwachen Sie, wie unterschiedlich die Front-End- und Backend-Server auf solche Manipulationen reagieren.
+- 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.
 
-### Testen von HTTP Request Smuggling-Schwachstellen
+### HTTP Request Smuggling Schwachstellentest
 
-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.
+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.
 
 **Wichtige Überlegungen**
 
 Beim Testen auf Request Smuggling-Schwachstellen durch Störung anderer Anfragen sollten Sie Folgendes beachten:
 
 - **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 Backend-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. 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 Backend-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.
+- **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.
 
-## Ausnutzen von HTTP Request Smuggling
+## Unterscheidung zwischen HTTP/1.1-Pipelining-Artefakten und echtem Request Smuggling
 
-### Umgehung der Front-End-Sicherheit durch HTTP Request Smuggling
+Die Wiederverwendung von Verbindungen (keep-alive) und Pipelining kann leicht Illusionen von "Smuggling" in Testtools erzeugen, die mehrere Anfragen über dasselbe Socket senden. Lernen Sie, harmlose clientseitige Artefakte von echten serverseitigen Desynchronisationen zu unterscheiden.
 
-Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch, die eingehende Anfragen überprüfen. Diese Maßnahmen können jedoch durch das Ausnutzen von HTTP Request Smuggling umgangen werden, 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.
+### Warum Pipelining klassische falsch-positive Ergebnisse erzeugt
 
-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:
+HTTP/1.1 verwendet eine einzige TCP/TLS-Verbindung und verknüpft Anfragen und Antworten im selben Stream. Beim Pipelining sendet der Client mehrere Anfragen hintereinander und verlässt sich auf in der Reihenfolge eintreffende Antworten. Ein häufiges falsch-positives Ergebnis besteht darin, eine fehlerhafte CL.0-ähnliche Nutzlast zweimal über eine einzige Verbindung zu senden:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Antworten können wie folgt aussehen:
+```
+HTTP/1.1 200 OK
+Content-Type: text/html
+
+```
+
+```
+HTTP/1.1 200 OK
+Content-Type: text/plain
+
+User-agent: *
+Disallow: /settings
+```
+Wenn der Server die fehlerhafte `Content_Length` ignorierte, gibt es keine FE↔BE-Desynchronisation. Bei der Wiederverwendung hat Ihr Client tatsächlich diesen Byte-Stream gesendet, den der Server als zwei unabhängige Anfragen interpretiert hat:
+```
+POST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: YPOST / HTTP/1.1
+Host: hackxor.net
+Content_Length: 47
+
+GET /robots.txt HTTP/1.1
+X: Y
+```
+Impact: keine. Sie haben lediglich 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".
+
+### 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 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
+- Senden Sie eine HTTP/2-Anfrage. Wenn der Antwortkörper eine vollständige verschachtelte HTTP/1-Antwort enthält, haben Sie einen Backend-Parsing-/Desynchronisationsfehler nachgewiesen, anstatt ein reines Client-Artefakt.
+3. Partial-Requests-Überprüfung für verbindungsgesperrte Front-Ends
+- Einige FEs verwenden die upstream BE-Verbindung nur wieder, wenn der Client seine wiederverwendet hat. Verwenden Sie Partial-Requests, um FE-Verhalten zu erkennen, das die Client-Wiederverwendung widerspiegelt.
+- Siehe PortSwigger "Browser‑Powered Desync Attacks" für die verbindungsgesperrte Technik.
+4. Status-Überprüfungen
+- Suchen Sie nach Unterschieden zwischen der ersten und den nachfolgenden Anfragen über dieselbe TCP-Verbindung (Routing/Validierung der ersten Anfrage).
+- Burp "HTTP Request Smuggler" enthält eine Verbindungsstatus-Überprüfung, die dies automatisiert.
+5. Visualisieren Sie die Verbindung
+- Verwenden Sie die Burp "HTTP Hacker"-Erweiterung, um die Verkettung und das Nachrichten-Framework direkt zu inspizieren, während Sie mit Wiederverwendung und Partial Requests experimentieren.
+
+### Verbindungsgesperrtes Request Smuggling (Wiederverwendung erforderlich)
+
+Einige Front-Ends verwenden die upstream-Verbindung nur wieder, wenn der Client seine wiederverwendet. Echte Smuggling existiert, ist jedoch von der clientseitigen Wiederverwendung abhängig. Um zu unterscheiden und den Einfluss nachzuweisen:
+- Nachweisen des serverseitigen Fehlers
+- Verwenden Sie den HTTP/2-Nested-Response-Check oder
+- 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.
+- 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.
+- 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.
+
+> Siehe auch Verbindungsstatusangriffe, die eng verwandt sind, aber technisch kein Smuggling sind:
+>
+>{{#ref}}
+>../http-connection-request-smuggling.md
+>{{#endref}}
+
+### Clientseitige Desynchronisationsbeschränkungen
+
+Wenn Sie browsergestützte/clientseitige Desynchronisation anvisieren, muss die bösartige Anfrage von einem Browser cross-origin sendbar sein. Header-Verschleierungstricks funktionieren nicht. Konzentrieren Sie sich auf Primitiven, die über Navigation/Fetch erreichbar sind, und pivotieren Sie dann zu Cache-Vergiftung, Header-Offenlegung oder Umgehung von Front-End-Kontrollen, wo nachgelagerte Komponenten Antworten widerspiegeln oder cachen.
+
+Für Hintergrundinformationen und End-to-End-Workflows:
+
+{{#ref}}
+-browser-http-request-smuggling.md
+{{#endref}}
+
+### Werkzeuge zur Entscheidungsfindung
+
+- HTTP Hacker (Burp BApp Store): zeigt niedrigstufiges HTTP-Verhalten und Socket-Verkettung an.
+- "Smuggling oder Pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
+- Turbo Intruder: präzise Kontrolle über die Verbindungswiederverwendung über `requestsPerConnection`.
+- 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.).
+
+## 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.
+
+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:
 
 **CL.TE Beispiel**
 ```
@@ -320,11 +426,11 @@ a=x
 0
 
 ```
-Im TE.CL-Angriff verwendet die ursprüngliche `POST`-Anfrage `Transfer-Encoding: chunked`, und die nachfolgende eingebettete Anfrage wird basierend auf dem `Content-Length`-Header verarbeitet. Ähnlich wie beim CL.TE-Angriff übersieht der Front-End-Proxy die geschmuggelte `GET /admin`-Anfrage und gewährt versehentlich Zugriff auf den eingeschränkten `/admin`-Pfad.
+Im Gegensatz dazu verwendet der TE.CL-Angriff die anfängliche `POST`-Anfrage mit `Transfer-Encoding: chunked`, und die nachfolgende eingebettete Anfrage wird basierend auf dem `Content-Length`-Header verarbeitet. Ähnlich wie beim CL.TE-Angriff übersieht der Front-End-Proxy die geschmuggelte `GET /admin`-Anfrage und gewährt versehentlich Zugriff auf den eingeschränkten `/admin`-Pfad.
 
-### Offenlegung der Front-End-Anforderungsumformung <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Offenlegung der Umformung von Front-End-Anfragen <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 modifizieren, bevor sie an den Back-End-Server weitergeleitet werden. Eine typische Modifikation 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 Modifikationen 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 modifizieren, bevor sie an den Back-End-Server weitergeleitet werden. Eine typische Modifikation 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 Modifikationen kann entscheidend sein, da es Möglichkeiten offenbaren könnte, **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:
 ```
@@ -379,13 +485,13 @@ In diesem Szenario ist der **Kommentarparameter** dazu gedacht, die Inhalte im K
 
 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.
 
-Darüber hinaus ist es erwähnenswert, dass dieser Ansatz auch bei einer TE.CL-Schwachstelle umsetzbar ist. In solchen Fällen sollte die Anfrage mit `search=\r\n0` enden. Unabhängig von Zeilenumbruchzeichen werden die Werte an den Suchparameter angehängt.
+Darüber hinaus ist es erwähnenswert, dass dieser Ansatz auch bei einer TE.CL-Schwachstelle anwendbar ist. In solchen Fällen sollte die Anfrage mit `search=\r\n0` enden. Unabhängig von Zeilenumbruchzeichen werden die Werte an den Suchparameter angehängt.
 
 ### Verwendung von HTTP-Request-Smuggling zur Ausnutzung von reflektiertem XSS
 
 HTTP Request Smuggling kann genutzt werden, um Webseiten auszunutzen, die anfällig für **reflektiertes XSS** sind, und bietet erhebliche Vorteile:
 
-- Interaktion mit den Zielbenutzern ist **nicht erforderlich**.
+- 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:
@@ -412,7 +518,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.
-2. Darauf folgt eine `0`, die das Ende des chunked Nachrichtentextes markiert.
+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.
 
 Durch die Manipulation des `User-Agent` durch Smuggling umgeht das Payload die normalen Anfragebeschränkungen und nutzt somit die Reflected XSS-Schwachstelle auf eine nicht standardmäßige, aber effektive Weise aus.
@@ -422,7 +528,7 @@ Durch die Manipulation des `User-Agent` durch Smuggling umgeht das Payload die n
 > [!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!
 
-Die Version HTTP/0.9 war vorher zu 1.0 und verwendet nur **GET**-Verben und **antwortet nicht** mit **Headers**, nur mit dem Body.
+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.
 
@@ -466,15 +572,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-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>
+### 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>
 
-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**.
+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**.
 
 Zuvor haben wir beobachtet, wie Serverantworten geändert werden konnten, um einen 404-Fehler zurückzugeben (siehe [Basic Examples](#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-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-Poisoning in Kombination mit einer Vor-Ort-Umleitung zu einer offenen Umleitung** dargestellt. Das Ziel ist es, den Cache-Inhalt von `/static/include.js` zu ändern, um JavaScript-Code bereitzustellen, der vom Angreifer kontrolliert wird:
+Nachfolgend ist eine Illustration des Ausnutzens von **Cache-Vergiftung 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
@@ -492,9 +598,9 @@ Content-Length: 10
 
 x=1
 ```
-Beachten Sie die eingebettete Anfrage, die auf `/post/next?postId=3` abzielt. Diese Anfrage wird auf `/post?postId=4` umgeleitet, wobei der **Host-Header-Wert** verwendet wird, um die Domain zu bestimmen. Durch die Änderung des **Host-Headers** kann der Angreifer die Anfrage auf seine Domain umleiten (**on-site redirect to open redirect**).
+Beachten Sie die eingebettete Anfrage, die auf `/post/next?postId=3` abzielt. Diese Anfrage wird auf `/post?postId=4` umgeleitet, wobei der **Host-Header-Wert** verwendet wird, um die Domain zu bestimmen. Durch Ändern des **Host-Headers** kann der Angreifer die Anfrage auf seine Domain umleiten (**On-Site-Redirect zu Open Redirect**).
 
-Nach erfolgreichem **Socket-Poisoning** sollte eine **GET-Anfrage** für `/static/include.js` initiiert werden. Diese Anfrage wird durch die vorherige **on-site redirect to open redirect**-Anfrage kontaminiert und ruft den Inhalt des vom Angreifer kontrollierten Skripts ab.
+Nach erfolgreicher **Socket-Poisoning** sollte eine **GET-Anfrage** für `/static/include.js` initiiert werden. Diese Anfrage wird durch die vorherige **On-Site-Redirect zu Open Redirect**-Anfrage kontaminiert und ruft den Inhalt des vom Angreifer kontrollierten Skripts ab.
 
 Anschließend wird jede Anfrage für `/static/include.js` den zwischengespeicherten Inhalt des Skripts des Angreifers bereitstellen, was effektiv einen umfassenden XSS-Angriff auslöst.
 
@@ -502,7 +608,7 @@ 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 aus dem Cache an andere Anwendungsbenutzer ausgeliefert.
+> - 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.
 
 Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible benutzerspezifische Inhalte abruft. Betrachten Sie das folgende Beispiel:
@@ -520,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 der Server die Methode TRACE aktiviert hat, 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, 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:
 ```
 TRACE / HTTP/1.1
 Host: example.com
@@ -537,13 +643,13 @@ Host: vulnerable.com
 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 beantwortet (**`Content-Type`** unter ihnen). Und schmuggeln Sie **unmittelbar nach dem HEAD eine TRACE-Anfrage**, die die **gesendeten Daten** widerspiegeln wird.\
+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 beantwortet (**`Content-Type`** unter ihnen). Und schmuggeln Sie **unmittelbar nach dem HEAD eine TRACE-Anfrage**, die die **gesendeten Daten** widerspiegelt.\
 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 widergespiegelt 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>
+### Ausnutzen 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>
 
-Es wird empfohlen, [**diesen Beitrag**](https://portswigger.net/research/trace-desync-attack) zu verfolgen, um eine weitere Möglichkeit zum Missbrauch der TRACE-Methode zu finden. Wie kommentiert, ist es durch das Schmuggeln einer HEAD-Anfrage und einer TRACE-Anfrage möglich, **einige widergespiegelte Daten** in der Antwort auf die HEAD-Anfrage zu **steuern**. Die Länge des Körpers der HEAD-Anfrage wird im Wesentlichen im Content-Length-Header angegeben und wird durch die Antwort auf die TRACE-Anfrage gebildet.
+Es wird empfohlen, [**diesen Beitrag**](https://portswigger.net/research/trace-desync-attack) zu verfolgen, um eine weitere Möglichkeit auszunutzen, die TRACE-Methode zu missbrauchen. Wie kommentiert, ist es durch das Schmuggeln einer HEAD-Anfrage und einer TRACE-Anfrage möglich, **einige widergespiegelte Daten** in der Antwort auf die HEAD-Anfrage zu steuern. Die Länge des Körpers der HEAD-Anfrage wird im Wesentlichen im Content-Length-Header angegeben und wird durch die Antwort auf die TRACE-Anfrage gebildet.
 
 Daher wäre die neue Idee, dass, wenn man diesen Content-Length und die in der TRACE-Antwort gegebenen Daten kennt, es möglich ist, die TRACE-Antwort so zu gestalten, dass sie eine gültige HTTP-Antwort nach dem letzten Byte des Content-Length enthält, was es einem Angreifer ermöglicht, die Anfrage zur nächsten Antwort vollständig zu steuern (was verwendet werden könnte, um eine Cache-Vergiftung durchzuführen).
 
@@ -587,9 +693,9 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### Waffenerstellung von HTTP Request Smuggling mit HTTP Response Desynchronisation
+### Waffeln von HTTP Request Smuggling mit HTTP Response Desynchronisation
 
-Haben Sie eine HTTP Request Smuggling-Schwachstelle gefunden und wissen nicht, wie Sie sie ausnutzen können? Versuchen Sie diese andere Methode der Ausnutzung:
+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:
 
 {{#ref}}
 ../http-response-smuggling-desync.md
@@ -698,6 +804,8 @@ table.add(req)
 ```
 ## Tools
 
+- HTTP Hacker (Burp BApp Store) – visualisiert die Verkettung/Framing und das Verhalten von HTTP auf niedriger Ebene
+- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
@@ -716,6 +824,10 @@ table.add(req)
 - [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/)
+- Achten Sie auf das falsche positives Ergebnis: wie man HTTP-Pipelining von Request Smuggling unterscheidet – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- [https://http1mustdie.com/](https://http1mustdie.com/)
+- Browser‑gestützte Desync-Angriffe – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- PortSwigger Academy – client‑seitige Desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
 
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md

@@ -2,6 +2,22 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-**Überprüfen Sie den Beitrag [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
+Browser-powered desync (auch bekannt als client-seitiges Request Smuggling) missbraucht den Browser des Opfers, um eine fehlerhaft formatierte Anfrage in eine gemeinsame Verbindung einzureihen, sodass nachfolgende Anfragen von einer nachgelagerten Komponente asynchron analysiert werden. Im Gegensatz zum klassischen FE↔BE Smuggling sind die Payloads durch das, was ein Browser legal cross-origin senden kann, eingeschränkt.
+
+Wichtige Einschränkungen und Tipps
+- Verwenden Sie nur Header und Syntax, die ein Browser über Navigation, Fetch oder Formularübermittlung senden kann. Header-Verschleierungen (LWS-Tricks, doppelte TE, ungültige CL) werden in der Regel nicht gesendet.
+- Zielen Sie auf Endpunkte und Zwischenstationen, die Eingaben widerspiegeln oder Antworten zwischenspeichern. Nützliche Auswirkungen sind Cache-Poisoning, das Leaken von front-end-injizierten Headern oder das Umgehen von front-end-Pfad-/Methoden-Kontrollen.
+- Wiederverwendung ist wichtig: Richten Sie die gestaltete Anfrage so aus, dass sie die gleiche HTTP/1.1- oder H2-Verbindung wie eine hochpriorisierte Opferanfrage teilt. Verbindungsgebundene/zustandsbehaftete Verhaltensweisen verstärken die Auswirkungen.
+- Bevorzugen Sie Primitive, die keine benutzerdefinierten Header erfordern: Pfadverwirrung, Query-String-Injektion und Body-Formung über form-encoded POSTs.
+- Validieren Sie echte serverseitige Desynchronisation vs. bloße Pipeline-Artefakte, indem Sie ohne Wiederverwendung erneut testen oder den HTTP/2-Nested-Response-Check verwenden.
+
+Für End-to-End-Techniken und PoCs siehe:
+- PortSwigger Research – Browser‑Powered Desync Attacks: https://portswigger.net/research/browser-powered-desync-attacks
+- PortSwigger Academy – client‑side desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
+
+## References
+- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- Unterscheidung zwischen Pipelining und Smuggling (Hintergrund zu Wiederverwendungs-Falsch-Positiven): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
 
 {{#include ../../banners/hacktricks-training.md}}