Was ist HTTP-Request-Smuggling?

HTTP-Request-Smuggling ist eine Sicherheitslücke, die durch Inkonsistenzen im HTTP-Anfrage-Parsing zwischen verschiedenen Geräten entsteht. Diese Schwachstellen treten auf, wenn ein Frontend-Gerät (z. B. CDN, Loadbalancer, WAF) und ein Backend-Gerät (z. B. Webserver) das Ende der HTTP-Anfrage unterschiedlich interpretieren, da unterschiedliche HTTP-Header vorhanden sind (z. B. Transfer-Encoding, Content-Length). Dies kann zur Umgehung von Sicherheitskontrollen, zur Möglichkeit, Angriffe (z. B. XSS) auf andere Nutzer zu starten, zu Cache-Poisoning, Denial-of-Service-Angriffen oder anderen Angriffen je nach Anwendung führen. HTTP-Request-Smuggling wird auch als CWE-444, HTTP-Antwort-Smuggling oder HTTP-Smuggling bezeichnet.

Es existieren viele Arten von HTTP-Request-Smuggling-Schwachstellen, abhängig von der Protokollversion, der Reihenfolge der Header und der Umgebung. Wir werden jeden dieser Punkte in den folgenden Abschnitten genauer erläutern.

Was wir behandeln werden:

Welche verschiedenen Arten von HTTP-Request-Smuggling gibt es?
HTTP/1.1-Request-Smuggling
HTTP/2-Request-Smuggling
Auswirkungen von HTTP-Request-Smuggling
Wie Fastly HTTP-Request-Smuggling verhindert
So verhindern Sie HTTP-Request-Smuggling
Zusammenfassung

Welche verschiedenen Arten von HTTP-Request-Smuggling gibt es?

HTTP/1.1-Request-Smuggling

HTTP-Anfragen mit Version 1.1 können das Ende ihrer Anfrage mit den Headern Content-Length oder Transfer-Encoding angeben. Wenn Frontend- und Backend-Geräte nicht denselben dieser beiden Header verwenden, um das Ende der Anfrage zu bestimmen, parsen sie das Ende der Anfrage möglicherweise unterschiedlich, was zu einer HTTP-Request-Smuggling-Sicherheitslücke führt.

Anhand der folgenden Beispiele werden wir die Auswirkungen des Request-Smuggling durch eine Autorisierungsumgehung veranschaulichen. In diesem Szenario verhindert der Frontend-Server den Zugriff auf die /admin-Seite, es gibt jedoch keine zusätzliche Validierung auf dem Backend. Da das Backend keine Validierung durchführt, können wir diese Autorisierungsprüfung durch Request-Smuggling umgehen.

CL.TE-Schwachstellen

Eine CL.TE-Schwachstelle bezieht sich auf einen HTTP-Request-Smuggling-Angriff, bei dem das Frontend den Content-Length-Header verwendet, das Backend jedoch den Transfer-Encoding-Header.

Im folgenden Beispiel verwendet das Frontend den Header Content-Length, liest den gesamten Inhalt als eine einzelne Anfrage und leitet ihn an das Backend weiter. Der Backend-Server verwendet jedoch den Transfer-Encoding-Header und interpretiert das Ende der Anfrage am 0\r\n\r\n (zwei neue Zeilen nach einem 0-Chunk, den Transfer-Encoding verwendet, um das Ende einer Anfrage anzuzeigen). Das Backend interpretiert dies somit als zwei Anfragen.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

0

GET /admin HTTP/1.1
Example: x

Nun, wenn mehr Daten durch die Verbindung kommen (z. B. wenn wir die Anfrage erneut senden), fügt der Backend-Server diese an diese „eingeschmuggelte“ zweite Anfrage an, da diese nicht abgeschlossen wurde. Dies führt dazu, dass der Backend-Server die folgende Anfrage als zweite Anfrage interpretiert:

GET /admin HTTP/1.1
Example: xPOST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

Der Backend-Server interpretiert dies als eine GET-Anfrage für /admin, die am Frontend-Server vorbeigeschmuggelt wurde, der nur die beiden POST-Anfragen interpretiert hat. Diese Request-Smuggling-Schwachstelle ermöglicht es dem Angreifer nun, die Autorisierungsprüfung durch das Frontend zu umgehen.

TE.CL-Schwachstellen

Eine TE.CL-Schwachstelle bezieht sich auf einen HTTP-Request-Smuggling-Angriff, bei dem das Frontend den Header Transfer-Encoding verwendet, das Backend jedoch den Header Content-Length.

Im folgenden Beispiel verwendet das Frontend den Header Transfer-Encoding, liest den gesamten Inhalt als eine einzelne Anfrage und leitet ihn an das Backend weiter. Das Backend verwendet den Header Content-Length und interpretiert diesen daher als zwei Anfragen.

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0
GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 150

x
0

Während der Frontend-Server seine einzige Anfrage abgeschlossen hat, wartet der Backend-Server noch auf zusätzliche Inhalte aus der langen Content-Length in der geschmuggelten Anfrage. Wenn mehr Daten durch die Verbindung kommen (z. B. wenn wir die Anfrage erneut senden), fügt der Backend-Server diese an diese „eingeschmuggelte“ zweite Anfrage an, da diese nicht abgeschlossen wurde. Dies führt dazu, dass der Backend-Server die folgende Anfrage als zweite Anfrage interpretiert:

GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 141

x
0

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0

Header-Verschleierung und Smuggling

Es ist möglich, dass einige Geräte Transfer-Encoding-Header ignorieren, die fehlerhaft sind, während andere sie selbst bei geringfügigen Fehlern (z. B. zusätzliche Leerzeichen, doppelte Header usw.) verarbeiten. In diesem Fall könnte es einfacher sein, eine der zuvor genannten CL.TE- oder TE.CL-Schwachstellen auszunutzen, da ein Gerät den fehlerhaften Header verarbeitet, während das andere ihn ignoriert.

HTTP/2-Request-Smuggling

Obwohl klassisches HTTP-Request-Smuggling durch HTTP/2 abgemildert werden sollte, gibt es immer noch Möglichkeiten, Anfragen mittels HTTP/2 zu schmuggeln, insbesondere wenn Backend-Server nur HTTP/1.1 unterstützen.

HTTP/2 ist ein binäres Protokoll, das in Frames übertragen wird, wobei jedem Frame die Länge des jeweiligen Frames vorangestellt wird. Ein Content-Length-Header ist nicht erforderlich, und der Transfer-Encoding-Header wird nicht unterstützt. Der Übersichtlichkeit halber stellen wir diese Anfragen so dar, wie sie in HTTP/1.1 aussehen würden; bitte beachten Sie jedoch, dass die tatsächlich gesendeten Daten in HTTP/2 anders aussehen.

HTTP/2-Downgrade

Wenn Backend-Geräte (z. B. Webserver) nur HTTP/1.1 unterstützen, Frontend-Geräte (z. B. CDNs) und Clients jedoch HTTP/2 verwenden, schreiben Frontend-Geräte ihre empfangene HTTP/2-Anfrage auf HTTP/1.1 um, bevor sie sie an das Backend senden. Dies wird als HTTP/2-Downgrading bezeichnet, und die Ausnutzung von Fehlern bei der Umschreibung ist der Grund, warum Request-Smuggling-Schwachstellen entstehen.

H2.CL-Schwachstellen

HTTP/2 benötigt keinen Content-Length-Header, und falls einer vorhanden ist, soll dieser gegen die berechnete Länge der Nachricht validiert werden. Wenn ein Gerät eine Anfrage auf HTTP/1.1 umschreibt, sollte es die berechnete Länge für den Content-Length-Header verwenden. Einige Frontend-Geräte verwenden jedoch stattdessen den bereitgestellten Content-Length-Header beim Downgrade. Wenn das passiert, verwendet das Back-End eine andere Content-Length als das Frontend, was zu einer Smuggling-Schwachstelle führt.

H2.TE-Schwachstellen

Der Transfer-Encoding-Header wird in HTTP/2 nicht verwendet, und es wird empfohlen, den Header entweder zu entfernen oder HTTP/2-Anfragen mit einem Transfer-Encoding-Header abzulehnen. Wenn das Frontend-Gerät das nicht tut und dann die Anfrage mit dem Transfer-Encoding-Header umschreibt, ist es möglich, den Header ins Backend zu schmuggeln. Um dies auszunutzen, müsste das Backend Transfer-Encoding über Content-Length unterstützen, wäre dann aber dasselbe wie eine CL.TE HTTP/1.1-Ausnutzung.

Auswirkungen von HTTP-Request-Smuggling

Das Smuggling von HTTP-Anfragen hat je nach Anwendung weitreichende Auswirkungen, da es die Grenzen mehrerer Anfragen beeinträchtigt. In unseren früheren Beispielen ging es um eine Umgehung der Autorisierung, und wir werden eine weitere behandeln, die sich auf andere Nutzer auswirkt. Es gibt jedoch viele weitere, die vom Team bei Portswigger, die umfangreiche Recherchen zum HTTP-Request-Smuggling durchführen, ausführlich behandelt werden.

Praxisbeispiel: Ausnutzung von reflektiertem XSS

In diesem Beispiel nehmen wir an, der Frontend-Server bestimmt die Anfragelänge basierend auf Content-Length, und der Backend-Server bestimmt sie anhand Transfer-Encoding. Nehmen wir auch an, der Webserver sei anfällig für reflektiertes Cross-Site Scripting (XSS), wenn sich eine Payload im Referrer-Header befindet. Normalerweise ist ein reflektiertes XSS im Referrer-Header schwer zu instrumentalisieren, da es nicht mit einem einfachen Link instrumentalisiert werden kann, wie es bei einem Query-Parameter der Fall wäre. In diesem Szenario sendet ein Angreifer die folgende Anfrage:

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 111
Transfer-Encoding: chunked

1
q=smuggling
0

GET /vulnerable-page HTTP/1.1
Referrer: ”><script>print(1)</script>
Example: x

Das Frontend verwendet den Content-Length-Header und interpretiert diesen als einzelne Anfrage, die an das Backend weitergeleitet wird. Das Backend verwendet Transfer-Encoding und interpretiert dies als zwei Anfragen, wobei die erste rot markiert und die zweite blau ist. Die zweite Anfrage ist unvollständig, daher wartet das Backend auf weitere Daten. Wenn ein anderer Nutzer danach eine Anfrage an /home sendet, stammt die Antwort des Webservers aus der geschmuggelten Anfrage des Angreifers, was dazu führt, dass die reflektierte XSS-Payload in der Antwort an den betroffenen Nutzer geliefert wird. In diesem Szenario interpretiert das Backend die Anfrage des betroffenen Nutzers wie folgt:

GET /vulnerable-page HTTP/1.1
Referrer: "><script>print(1)</script>
Example: xGET /home HTTP/1.1
Host: example.com
...rest of victim user's request...

Der betroffene Nutzer sendete eine Anfrage an /home, erhielt aber stattdessen die Antwort auf /vulnerable-page mit der reflektierten XSS-Payload. In der Praxis sind aufgrund des Anfragevolumens, der Wiederverwendung von Verbindungen usw. zahlreiche Anfragen erforderlich, bis ein Nutzer die in der Warteschlange befindliche XSS-Antwort erhält; dies kann jedoch schnell eine große Anzahl von Nutzern betreffen, indem in rascher Folge Smuggling-Anfragen gesendet werden, um Verbindungen mit XSS-Nutzdaten zu infizieren.

Wie Fastly HTTP-Request-Smuggling verhindert

Fastly verhindert HTTP-Request-Smuggling durch strikte und konforme Analyse von Anfragen. Dies geschieht auf verschiedene Weise:

Striktes Protokollparsing: Fastly parst alle HTTP-Anfragen mit hoher Strenge und hält sich an die Standards. Dadurch wird die Mehrdeutigkeit beseitigt, die Angreifer nutzen, um Request-Smuggling-Sicherheitslücken zu instrumentalisieren.
Anfrage-Normalisierung: Fastly lehnt mehrdeutige Anfragen entweder auf der Edge ab oder normalisiert sie. Beispielsweise wird eine Anfrage, die sowohl einen Content-Length- als auch einen Transfer-Encoding-Header enthält, entsprechend verarbeitet, um zu verhindern, dass sie Ihren Origin-Server in einem ausnutzbaren Zustand erreicht.
Ablehnung ungültiger Anfragen: Fastly lehnt GET- und HEAD-Anfragen ab, die einen Body enthalten. Wenn dies geschieht, sendet Fastly eine 400 Bad Request-Antwort, die verhindert, dass die Anfrage den Ursprung erreicht. Wenn die Konfiguration es zulässt, werden pass-Anfragen die GET- und HEAD-Anfrage mit Body an den Ursprung übertragen. Wenn Sie einen spezifischen Bedarf haben, Bodys für diese Anfragen zu aktivieren, müssen Sie unser Support-Team kontaktieren.

So verhindern Sie HTTP-Request-Smuggling

Normalisieren Sie mehrdeutige Anfragen
- Frontend-Server, die sowohl CL- als auch TE-Header empfangen, sollten Anfragen auf einen einheitlichen Mechanismus zur Ermittlung der Anfragelänge normalisieren und die überflüssigen Header entfernen, um zu verhindern, dass die Ursprungsserver mehrdeutige Anfragen erhalten.
Lehnen Sie fehlerhaft formatierte Anfragen ab (sowohl HTTP/2 als auch HTTP/1.1)
- Das Ablehnen von Anfragen mit fehlerhaften Headern, doppelten Headern usw. trägt dazu bei, Sicherheitslücken zu vermeiden, die darauf beruhen, dass Server fehlerhafte Header akzeptieren. Außerdem werden dadurch HTTP/2-Downgrade-CL- und TE-Schwachstellen verhindert, die darauf beruhen, dass zusätzliche, unnötige Header an das Backend weitergeleitet werden.
Führen Sie bei einem Downgrade auf HTTP/1.1 eine Validierung durch
- Frontend-Server, die auf HTTP/1.1 herabgestuft werden, sollten überprüfen, dass umgeschriebene Anfragen nicht fehlerhaft oder mehrdeutig sind. Zum Beispiel sollte ein Frontend-Server nach dem Umschreiben die gleiche Normalisierung ausführen wie bei einer regulären HTTP/1.1-Anfrage.
Erwägen Sie, die Wiederverwendung von Backend-Verbindungen zu deaktivieren
- Bei vielen Request-Smuggling-Angriffen werden Verbindungen zwischen Frontend und Backend wiederverwendet. Das XSS-Beispiel veranschaulicht dies: Wenn mehrere Nutzer, die Anfragen senden, eine gemeinsame Verbindung vom Frontend zum Backend nutzen, führt das Smuggling dazu, dass die Antworten miteinander vermischt werden. Die Deaktivierung der Wiederverwendung von Verbindungen verhindert diese Art von Angriffen, schützt jedoch nicht vor allen Smuggling-Angriffen und verhindert auch keine fortgeschrittenen Techniken wie Request-Tunneling. Dies kann sich zudem auf die Leistung auswirken und stellt lediglich eine teilweise Abhilfe dar.
Verwenden Sie nach Möglichkeit durchgehend HTTP/2
- HTTP/2 ist von Natur aus gegen Request-Smuggling geschützt, wenn Downgrading deaktiviert ist. Wenn möglich, ist die Verwendung die beste Abwehr.

Zusammenfassung

Beim HTTP-Request-Smuggling handelt es sich um eine Sicherheitslücke, die durch Inkonsistenzen bei der Verarbeitung von HTTP-Anfragen zwischen verschiedenen Geräten entsteht und verheerende Auswirkungen haben kann, wie z. B. die Umgehung von Autorisierung, die Möglichkeit, Angriffe (z. B. XSS) auf andere Nutzer zu starten, Cache-Poisoning, Denial-of-Service-Angriffe und mehr. Während HTTP/2 und das Deaktivieren des Downgradings Request-Smuggling verhindern, sollten Organisationen auch in Erwägung ziehen, fehlerhaft formulierte Anfragen abzulehnen, mehrdeutige Anfragen zu normalisieren und das HTTP-Schema zu validieren, um die Angriffs-Oberfläche weiter zu begrenzen, falls ein Downgrading unterstützt werden muss.

Erfahren Sie mehr über die Sicherheitsangebote von Fastly, die Sie vor HTTP-Request-Smuggling-Angriffen und mehr schützen können.

Learn more about Fastly’s security offerings

Mehr erfahren