Was ist HTTP-Request-Smuggling? Tutorial & Beispiele | Web-Sicherheitsakademie (2024)

In diesem Abschnitt erläutern wir Angriffe zum Schmuggel von HTTP-Anfragen und beschreiben, wie häufig Schwachstellen beim Schmuggel von Anfragen auftreten können.

Was ist HTTP-Request-Smuggling?

Das Schmuggeln von HTTP-Anfragen ist eine Technik zur Beeinträchtigung der Art und Weise, wie eine Website Sequenzen von HTTP-Anfragen verarbeitet, die von einem oder mehreren Benutzern empfangen werden. Schwachstellen beim Schmuggel von Anfragen sind häufig kritischer Natur und ermöglichen es einem Angreifer, Sicherheitskontrollen zu umgehen, sich unbefugten Zugriff auf sensible Daten zu verschaffen und andere Anwendungsbenutzer direkt zu gefährden.

Was passiert bei einem HTTP-Request-Smuggling-Angriff?

Heutige Webanwendungen nutzen häufig Ketten von HTTP-Servern zwischen Benutzern und der ultimativen Anwendungslogik. Benutzer senden Anfragen an einen Front-End-Server (manchmal auch als Load Balancer oder Reverse Proxy bezeichnet) und dieser Server leitet Anfragen an einen oder mehrere Back-End-Server weiter. Diese Art von Architektur ist in modernen Cloud-basierten Anwendungen immer häufiger und in manchen Fällen unvermeidbar.

Wenn der Front-End-Server HTTP-Anfragen an einen Back-End-Server weiterleitet, sendet er normalerweise mehrere Anfragen über dieselbe Back-End-Netzwerkverbindung, da dies wesentlich effizienter und leistungsfähiger ist. Das Protokoll ist sehr einfach: HTTP-Anfragen werden nacheinander gesendet und der empfangende Server analysiert die Header der HTTP-Anfrage, um festzustellen, wo eine Anfrage endet und die nächste beginnt:

In dieser Situation ist es entscheidend, dass sich die Front-End- und Back-End-Systeme über die Grenzen zwischen Anfragen einig sind. Andernfalls könnte ein Angreifer möglicherweise eine mehrdeutige Anfrage senden, die von den Front-End- und Back-End-Systemen unterschiedlich interpretiert wird:

Dabei sorgt der Angreifer dafür, dass ein Teil seiner Front-End-Anfrage vom Back-End-Server als Beginn der nächsten Anfrage interpretiert wird. Es wird praktisch der nächsten Anfrage vorangestellt und kann daher die Art und Weise beeinträchtigen, wie die Anwendung diese Anfrage verarbeitet. Hierbei handelt es sich um einen Anforderungsschmuggelangriff, der verheerende Folgen haben kann.

Wie entstehen Schwachstellen beim Schmuggel von HTTP-Anfragen?

Die meisten Schwachstellen beim Schmuggel von HTTP-Anfragen entstehen, weil die HTTP-Spezifikation zwei verschiedene Möglichkeiten bietet, anzugeben, wo eine Anfrage endet: dieInhaltslängeKopfzeile und dieTransfer-KodierungHeader.

DerInhaltslängeDer Header ist unkompliziert: Er gibt die Länge des Nachrichtentexts in Bytes an. Zum Beispiel:

POST /search HTTP/1.1Host: normal-website.comContent-Type: application/x-www-form-urlencodedContent-Length: 11q=smuggling

DerTransfer-KodierungDer Header kann verwendet werden, um anzugeben, dass der Nachrichtentext eine Chunked-Codierung verwendet. Das bedeutet, dass der Nachrichtentext einen oder mehrere Datenblöcke enthält. Jeder Block besteht aus der Blockgröße in Bytes (ausgedrückt in Hexadezimalzahl), gefolgt von einer neuen Zeile und dem Inhalt des Blocks. Die Nachricht wird mit einem Block der Größe Null abgeschlossen. Zum Beispiel:

POST /search HTTP/1.1Host: normal-website.comContent-Type: application/x-www-form-urlencodedTransfer-Encoding: chunkedbq=smuggling0

Da die HTTP-Spezifikation zwei unterschiedliche Methoden zur Angabe der Länge von HTTP-Nachrichten bereitstellt, ist es möglich, dass eine einzelne Nachricht beide Methoden gleichzeitig verwendet, sodass sie miteinander in Konflikt geraten. Die HTTP-Spezifikation versucht, dieses Problem zu verhindern, indem sie angibt, dass, wenn beideInhaltslängeUndTransfer-KodierungHeader vorhanden sind, dann dieInhaltslängeDer Header sollte ignoriert werden. Dies reicht möglicherweise aus, um Unklarheiten zu vermeiden, wenn nur ein einzelner Server im Spiel ist, nicht jedoch, wenn zwei oder mehr Server miteinander verkettet sind. In dieser Situation können aus zwei Gründen Probleme auftreten:

• Einige Server unterstützen das nichtTransfer-KodierungHeader in Anfragen.
• Einige Server, die das unterstützenTransfer-KodierungDer Header kann veranlasst werden, ihn nicht zu verarbeiten, wenn der Header auf irgendeine Weise verschleiert ist.

Wenn sich die Front-End- und Back-End-Server in Bezug auf die (möglicherweise verschleierte)Transfer-Kodierungenthalten, sind sie sich möglicherweise nicht einig über die Grenzen zwischen aufeinanderfolgenden Anfragen, was zu Schwachstellen beim Schmuggel von Anfragen führen kann.

So führen Sie einen HTTP-Request-Smuggling-Angriff durch

Bei Request-Smuggling-Angriffen werden beide Seiten platziertInhaltslängeKopfzeile und dieTransfer-Kodierung-Header in eine einzelne HTTP-Anfrage umwandeln und diese so manipulieren, dass die Front-End- und Back-End-Server die Anfrage unterschiedlich verarbeiten. Die genaue Art und Weise, wie dies geschieht, hängt vom Verhalten der beiden Server ab:

• CL.TE: Der Front-End-Server verwendet dieInhaltslängeHeader und der Back-End-Server verwendet denTransfer-KodierungHeader.
• TE.CL: Der Front-End-Server verwendet dieTransfer-KodierungHeader und der Back-End-Server verwendet denInhaltslängeHeader.
• TE.TE: Sowohl die Front-End- als auch die Back-End-Server unterstützen dasTransfer-KodierungHeader, aber einer der Server kann dazu gebracht werden, ihn nicht zu verarbeiten, indem der Header auf irgendeine Weise verschleiert wird.

CL.TE-Schwachstellen

Hier verwendet der Front-End-Server dieInhaltslängeHeader und der Back-End-Server verwendet denTransfer-KodierungHeader. Wir können einen einfachen HTTP-Request-Smuggling-Angriff wie folgt durchführen:

POST / HTTP/1.1Host: vulnerable-website.comContent-Length: 13Transfer-Encoding: chunked0GESCHMUGGELT

Der Front-End-Server verarbeitet dieInhaltslängeHeader und stellt fest, dass der Anforderungstext bis zum Ende 13 Byte lang istGESCHMUGGELT. Diese Anfrage wird an den Back-End-Server weitergeleitet.

Der Back-End-Server verarbeitet dieTransfer-KodierungHeader und behandelt den Nachrichtentext daher so, als würde er eine Chunked-Codierung verwenden. Es verarbeitet den ersten Block, der angeblich eine Länge von Null hat, und wird daher so behandelt, als würde die Anforderung beendet. Die folgenden Bytes,GESCHMUGGELT, bleiben unverarbeitet und werden vom Back-End-Server als Beginn der nächsten Anfrage in der Sequenz behandelt.

TE.CL-Schwachstellen

Hier verwendet der Front-End-Server dieTransfer-KodierungHeader und der Back-End-Server verwendet denInhaltslängeHeader. Wir können einen einfachen HTTP-Request-Smuggling-Angriff wie folgt durchführen:

POST / HTTP/1.1Host: vulnerable-website.comInhaltslänge: 3Übertragungskodierung: chunked8geschmuggelt0

Der Front-End-Server verarbeitet dieTransfer-KodierungHeader und behandelt den Nachrichtentext daher so, als würde er eine Chunked-Codierung verwenden. Es verarbeitet den ersten Block, der angeblich 8 Byte lang ist, bis zum Anfang der folgenden ZeileGESCHMUGGELT. Es verarbeitet den zweiten Block, der angeblich eine Länge von Null hat, und wird daher so behandelt, als würde die Anforderung beendet. Diese Anfrage wird an den Back-End-Server weitergeleitet.

Der Back-End-Server verarbeitet dieInhaltslängeHeader und stellt fest, dass der Anforderungstext bis zum Anfang der folgenden Zeile 3 Byte lang ist8. Die folgenden Bytes, beginnend mitGESCHMUGGELT, bleiben unverarbeitet und werden vom Back-End-Server als Beginn der nächsten Anfrage in der Sequenz behandelt.

TE.TE-Verhalten: Verschleierung des TE-Headers

Hier unterstützen sowohl die Front-End- als auch die Back-End-ServerTransfer-KodierungHeader, aber einer der Server kann dazu gebracht werden, ihn nicht zu verarbeiten, indem der Header auf irgendeine Weise verschleiert wird.

Es gibt potenziell endlose Möglichkeiten, das zu verschleiernTransfer-KodierungHeader. Zum Beispiel:

Transfer-Encoding: xchunkedTransfer-Encoding: chunkedTransfer-Encoding: chunkedTransfer-Encoding: xTransfer-Encoding:[tab]chunked[space]Transfer-Encoding: chunkedX: X[\n]Transfer-Encoding: chunkedTransfer-Encoding: chunked

Jede dieser Techniken beinhaltet eine subtile Abweichung von der HTTP-Spezifikation. Realer Code, der eine Protokollspezifikation implementiert, hält sich selten mit absoluter Präzision daran, und es ist üblich, dass unterschiedliche Implementierungen unterschiedliche Abweichungen von der Spezifikation tolerieren. Um eine TE.TE-Schwachstelle aufzudecken, ist es notwendig, eine Variation davon zu findenTransfer-KodierungHeader so, dass nur einer der Front-End- oder Back-End-Server ihn verarbeitet, während der andere Server ihn ignoriert.

Je nachdem, ob es der Front-End- oder der Back-End-Server ist, kann man dazu bringen, das Verschleierte nicht zu verarbeitenTransfer-KodierungHeader wird der Rest des Angriffs die gleiche Form annehmen wie für die bereits beschriebenen CL.TE- oder TE.CL-Schwachstellen.

So identifizieren Sie Schwachstellen beim Schmuggel von HTTP-Anfragen

Im folgenden Abschnitt finden Sie einige Tipps, wie Sie selbst Schwachstellen beim Schmuggel von HTTP-Anfragen identifizieren können. Wir haben auch einige interaktive Inhalte bereitgestelltLABOR, damit Sie sehen können, wie das in der Praxis funktioniert.

So nutzen Sie Schwachstellen beim Schmuggel von HTTP-Anfragen aus

Nachdem Sie nun mit den Grundkonzepten vertraut sind, werfen wir einen Blick darauf, wie der Schmuggel von HTTP-Anfragen für die Durchführung einer Reihe schwerwiegender Angriffe genutzt werden kann. Wie üblich gibt es viele vollständig interaktive SpieleLABOR, sodass Sie versuchen können, realistische Ziele anzugreifen.

Erweiterter HTTP-Anforderungsschmuggel

Wenn Sie den Rest unserer Labore zum Schmuggel von Anfragen bereits abgeschlossen haben, sind Sie bereit, einige fortgeschrittenere Techniken zu erlernen. Wir haben eine Reihe interaktiver erstelltLABORBasierend auf realen Schwachstellen, die von PortSwigger-Forschern entdeckt wurden. Sie haben sogar die Möglichkeit, die einzigartigen Funktionen von Burp für HTTP/2-basierte Tests auszuprobieren.

Browsergestützter Anforderungsschmuggel

Die Techniken zum Schmuggel von Anfragen, die Sie bisher kennengelernt haben, basieren auf dem Senden absichtlich fehlerhafter Anfragen mithilfe spezieller Hacking-Tools wie Burp Repeater. Tatsächlich ist es möglich, dieselben Angriffe mit vollständig browserkompatiblen Anfragen auszuführen, die die beiden Server auf völlig normale Weise desynchronisierenInhaltslängeHeader.

Dies ermöglicht Ihnen sogar, clientseitige Varianten dieser Angriffe zu starten, die den Browser eines Opfers dazu veranlassen, seine eigene Verbindung zur anfälligen Website zu verfälschen. Dadurch werden einzelne Server-Sites nicht nur anfällig für Schmuggelangriffe, sondern Sie können auch Sites angreifen, auf die Sie keinen direkten Zugriff haben. Schauen Sie sich die Lernmaterialien an undLABORum zu lernen, wie.

So verhindern Sie Schwachstellen beim Schmuggel von HTTP-Anfragen

Schwachstellen beim HTTP-Anforderungsschmuggel entstehen in Situationen, in denen der Front-End-Server und der Back-End-Server unterschiedliche Mechanismen zur Bestimmung der Grenzen zwischen Anforderungen verwenden. Dies kann auf Diskrepanzen zwischen der Verwendung von HTTP/1-Servern zurückzuführen seinInhaltslängeHeader- oder Chunked-Transfer-Codierung, um zu bestimmen, wo jede Anfrage endet. In HTTP/2-Umgebungen ist die übliche Praxis vonHerabstufung von HTTP/2-AnfragenDenn auch das Backend ist problematisch und ermöglicht bzw. vereinfacht eine Reihe zusätzlicher Angriffe.

Um Schwachstellen beim Schmuggel von HTTP-Anfragen zu verhindern, empfehlen wir die folgenden allgemeinen Maßnahmen:

• Verwenden Sie HTTP/2 End-to-End und deaktivieren Sie das HTTP-Downgrade, wenn möglich. HTTP/2 verwendet einen robusten Mechanismus zur Bestimmung der Länge von Anfragen und ist bei End-to-End-Nutzung von Natur aus vor dem Schmuggel von Anfragen geschützt. Wenn Sie ein HTTP-Downgrade nicht vermeiden können, stellen Sie sicher, dass Sie die umgeschriebene Anfrage anhand der HTTP/1.1-Spezifikation validieren. Lehnen Sie beispielsweise Anfragen ab, die Zeilenumbrüche in den Headern, Doppelpunkte in Headernamen und Leerzeichen in der Anfragemethode enthalten.

• Lassen Sie den Front-End-Server mehrdeutige Anfragen normalisieren und veranlassen Sie den Back-End-Server, alle noch mehrdeutigen Anfragen abzulehnen und dabei die TCP-Verbindung zu schließen.

• Gehen Sie niemals davon aus, dass Anfragen keinen Text haben. Dies ist die Hauptursache für CL.0- und clientseitige Desynchronisierungsschwachstellen.

• Standardmäßig wird die Verbindung verworfen, wenn bei der Verarbeitung von Anforderungen Ausnahmen auf Serverebene ausgelöst werden.

• Wenn Sie Datenverkehr über einen Forward-Proxy weiterleiten, stellen Sie sicher, dass Upstream-HTTP/2 nach Möglichkeit aktiviert ist.

Wie wir in den Lernmaterialien gezeigt haben, hilft die Deaktivierung der Wiederverwendung von Back-End-Verbindungen dabei, bestimmte Arten von Angriffen abzuschwächen, schützt Sie jedoch immer noch nicht davorTunneling anfordernAnschläge.