Was ist HTTP-Request-Smuggling?
HTTP-Anfrage in HTTP-Anfrage ausblenden. Das ist die Grundidee. Ganz einfach, oder?
Nun, wir können sagen, dass HTTP Request Smuggling eine Technik ist, um die Fehlkonfiguration auszunutzen. Ein Algorithmus, der in Reverse-Proxys oder auf den Back-End-Servern eingeführt wird, indem er nicht die richtigen RFC-Standardspezifikationen anwendet, um eine völlig neue HTTP-Anfrage einzuschleusen.
Warum?
Um das Surferlebnis und die Geschwindigkeit des Benutzers zu verbessern und die Belastung des Hauptservers zu verringern, verwenden viele Websites CDN (Content Delivery Network) wie Cloudflare, das als Reverse-Proxy fungiert und die statischen Dateien zwischenspeichert, sodass sie sofort geladen werden können Senden einer Anfrage an den Hauptserver.
Wenn ein Benutzer also eine statische Datei anfordert, kann diese direkt aus dem Cache des CDN geladen werden.
Bei der Bereitstellung der Antwort auf die Anfrage eines Benutzers sind zwei verschiedene Server beteiligt.
Wenn wir beispielsweise eine HTML-Webseite anfordern, enthält diese viele Dateien wie CSS, JavaScript oder Bilder, die nicht spezifisch für einen bestimmten Benutzer sind, außerdem einige benutzerspezifische Inhalte wie Benutzerprofildetails wie Benutzername und E-Mail, bei denen es sich um dynamisch generierte Inhalte handelt . Ein intelligentes CDN erkennt dies und speichert die statischen Dateien auf dem eigenen Server zwischen. Wenn also die Anfrage eines neuen Benutzers beim CDN ankommt, stellt es die statischen Dateien selbst für dynamische Inhalte bereit und leitet die Anfrage dann an die Haupt-Back-End-Server weiter. Aber hier ist der lustige Teil: Die vom CDN an den Hauptserver weitergeleitete Anfrage ist eine modifizierte Version der Hauptbenutzeranfrage. Das CDN fügt einige eindeutige Header hinzu, die dem Hauptserver helfen, die vom CDN kommende Anfrage zu identifizieren.
Da diese Server zwei verschiedenen Parteien gehören, müssen sie zwangsläufig unterschiedlich konfiguriert werden. Daher verarbeiten sie jede HTTP-Anfrage unterschiedlich. und das ist die Hauptursache für den HTTP-Schmuggel.
WIE?
Bevor wir auf das „Wie“ eingehen, sollten wir uns einen kurzen Überblick über die Content-Length- und Transfer-Encoding-Header verschaffen, da diese Header die Schlüsselelemente für diesen Angriff sind.
- Inhaltslänge:
Mit diesem speziellen Header können wir die Größe der Nachricht (Postdaten) der HTTP-Anfrage in Bytes definieren.
Syntax
- Transfer-Kodierung:
Es gibt an, dass der Nachrichtentext eine Chunked-Codierung verwendet. Das heißt, die Nachricht enthält einen oder mehrere Datenblöcke.
Syntax
Lassen Sie uns tief in die technischen Details eintauchen, ja?
Wie oben erwähnt, sind zwei Server an der Verarbeitung der HTTP-Anfrage eines Benutzers beteiligt. Wenn also eine fehlerhafte HTTP-Anfrage eingeht, behandeln beide Server diese Anfrage auf unterschiedliche Weise. Dies eröffnet einem Angreifer ein einzigartiges Zeitfenster.
Wenn beispielsweise eine HTTP-Anfrage eingegeben wird, die Folgendes enthält:InhaltslängeKopfzeile sowie aTransfer-KodierungHeader, wie die folgende Anfrage, wird von beiden Servern unterschiedlich behandelt.
Wenn nun gemäß dem RFC-Standard eine HTTP-Anfrage beides enthältCLUndDERHeader, dann sollte der CL-Header ignoriert werden. Es gibt jedoch viele Server, die nicht gemäß RFC konfiguriert sind. Indem ein Angreifer eine böswillige Anfrage erstellt und den Serverprozessor des Headers herausfindet, kann er die HTTP-Anfrage in die HTTP-Anfrage einschleusen.
Ähm... scheint kompliziert? Machen wir es einfach. Betrachten Sie das folgende Szenario:
Hier haben wir 2 Server namens CDN und Hauptserver.
Wenn eine HTTP-Anfrage mit beiden Headern eingeht, gibt das CDN dem CL-Header Vorrang und der Hauptserver dem TE-Header Vorrang.
Wenn also ein Angreifer diese Anfrage sendet, behandelt das CDN die CL-Header und leitet die gesamte Anfrage unverändert an den Hauptserver weiter.
Jetzt behandelt der Hauptserver nur den TE-Header und schließt die TCP-Verbindung, sobald er das abschließende Chunked empfängt. Der verbleibende Teil wird nicht verarbeitet. Der hervorgehobene Teil bleibt also in der Pipeline hängen.
Ziemlich cool, oder? Aber warte. Dies ist nur Phase 1, der wahre Spaß beginnt jetzt.
Jetzt hängt der geschmuggelte Teil in der Pipeline und wenn eine neue HTTP-Anfrage kommt,
Der geschmuggelte Teil wird dieser Anfrage direkt vorangestellt oder vorangestellt, wie unten dargestellt
und der Benutzer erhält eine Antwort wie folgt:
Dies ist die Grundidee des HTTP-Schmuggels.
Ich hoffe, dies hilft Ihnen, das Kernkonzept dieses Angriffs zu verstehen.
Angriffsszenarien?
- CL.TE
Das bedeutet, wenn eine HTTP-Anfrage beides enthältCunentschlossenLLänge undTTransfer-EWenn der Ncoding-Header eintrifft, verarbeitet der Front-End-Server den Content-Length-Header und das Backend verarbeitet den Transfer-Encoding-Header. Und der markierte Teil wird geschmuggelt.
- TE.CL
Das heißt, wenn eine HTTP-Anfrage eintrifft, die sowohl den Content-Length- als auch den Transfer-Encoding-Header enthält, verarbeitet der Front-End-Server den Transfer-Encoding-Header und das Backend den Content-Length-Header, wodurch der hervorgehobene Teil geschmuggelt wird.
DIE ... DIE
Das heißt, wenn eine HTTP-Anfrage, die den Transfer-Encoding-Header enthält, zweimal in einer Anfrage vorkommt, wird einer der Header leicht verschleiert, sodass einer der Server dazu veranlasst werden kann, ihn nicht zu verarbeiten.
Während dies die beliebtesten Angriffsszenarien sind, gibt es zwei weitere Szenarien, die selten sind, aber häufig ausgenutzt werden können.
Versteckte Angriffsszenarien
- GET-Anfrage mit CL! = 0
Wir wissen, dass GET-Anfragen keinen Post-Body haben, aber im RFC-Standard ist so etwas nicht vorgesehen. Es heißt lediglich, dass die Server diese möglicherweise ablehnen, wenn Sie Postdaten zusammen mit der GET-Anfrage senden. Wenn der Server einen solchen Fall jedoch aufgrund einer Fehlkonfiguration zulässt, kann er im Handumdrehen ausgenutzt werden.
- CL.CL
Auch das ist ein interessanter Fall. Wenn eine HTTP-Anfrage zwei Content-Length-Header enthält, sollte der Server laut RFC den Fehler 400 ausgeben.
Aber wie wir bereits wissen, setzen die meisten Server die Spezifikationen nicht strikt um. Das Front-End verarbeitet also den ersten Header und das Back-End verarbeitet den zweiten Content-Length-Header, wodurch der hervorgehobene Teil geschmuggelt wird.
Ausbeutungsszenarien?
Während wir den PoC für den HTTP-Schmuggel angeben, müssen wir die Auswirkungen aufzeigen, die er hat. Daher können wir die folgenden Fälle verwenden, um die Auswirkungen dieser Sicherheitslücke aufzuzeigen. Lassen Sie uns nicht auf die technischen Details dieser Ausbeutung eingehen, sondern auf die Logik dahinter, die Sie interessieren wird. Um dies besser zu verstehen, können Sie PortSwiggers Labor zum Thema HTTP-Schmuggel ausprobieren.
Verwendung des HTTP-Anforderungsschmuggels zur Umgehung von Front-End-Sicherheitskontrollen:
Oftmals ist das Admin-Panel für normale Benutzer nicht zugänglich. Wenn wir also die Schwachstelle finden, können wir sie nutzen, um das Admin-Panel zu erreichen, indem wir Anfragen an den Admin-Endpunkt schmuggeln.
Offenlegung der Neuformulierung von Front-End-Anfragen
In vielen Anwendungen führt der Front-End-Server einige Umschreibungen von Anforderungen durch, bevor sie an den Back-End-Server weitergeleitet werden, typischerweise durch Hinzufügen einiger zusätzlicher Anforderungsheader. An Stellen, an denen die POST-Daten widergespiegelt werden, kann diese Schwachstelle zum Schreiben der gesamten Anforderungsthreads ausgenutzt werden.
Erfassen der Anfragen anderer Benutzer
Im Vergleich zum vorherigen Szenario kann es verwendet werden, um autorisierungsspezifische Header von anderen Benutzern wie Cookies oder Token widerzuspiegeln.
Verwendung des HTTP-Anforderungsschmuggels, um reflektiertes XSS auszunutzen
Wenn eine Anwendung anfällig für HTTP-Request-Smuggling ist und auch reflektiertes XSS enthält, können Sie einen Request-Smuggling-Angriff nutzen, um andere Benutzer der Anwendung mit dem reflektierten XSS zu treffen.
Verwendung des HTTP-Anforderungsschmuggels, um eine offene Weiterleitung zu verursachen
Sie können diese Schwachstelle, die eine Site-Wide-Open-Weiterleitung verursacht, ausnutzen, indem Sie eine von einem Angreifer kontrollierte Domäne in die Domäne einschleusenGastgeberHeader. Als Referenz für diese Ausbeutunghttps://hackerone.com/reports/694604
Verwendung des HTTP-Request-Smuggels zur Durchführung von Web-Cache-Poisoning oder Web-Cache-Täuschung
Wenn ein Teil der Front-End-Server eine Zwischenspeicherung der Inhalte durchführt, um die Geschwindigkeit der Bereitstellung von Inhalten zu verbessern, kann es sein, dass der Cache durch eine externe Umleitungsantwort vergiftet wird. Aus diesem Grund wird der Angriff anhaltend sein und andere Benutzer beeinträchtigen, die anschließend die betroffene URL anfordern und unsere vergifteten Cache-Inhalte erhalten. In einer weiteren Variante des Angriffs können Sie den HTTP-Request-Smuggel nutzen, um Web-Cache-Deception-Angriffe durchzuführen. Dies funktioniert ähnlich wie der Web-Cache-Poisoning-Angriff, verfolgt jedoch einen anderen Zweck.
Ich habe versucht, das Konzept des HTTP-Schmuggels so zu vereinfachen, wie ich es verstand. Ich hoffe, dieser Artikel hilft Ihnen irgendwie. Sollten Sie einmal nicht weiterkommen, können Sie Ihre Fragen gerne an uns weiterleiten.
Referenz:
1. https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
2. https://i.blackhat.com/USA-19/Wednesday/us-19-Kettle-HTTP-Desync-Attacks-Smashing-Into-The-Cell-Next-Door.pdf