Entmystifizierung des HTTP-Anfrageschmuggels | Snyk (2024)

Das Schmuggeln von HTTP-Anfragen ist ein interessanter Schwachstellentyp, der im letzten Jahr an Popularität gewonnen hat. Diese Sicherheitslücke könnte es einem Angreifer ermöglichen, bestimmte Funktionen des HTTP/1.1-Protokolls auszunutzen, um Sicherheitsmaßnahmen zu umgehen, Phishing-Angriffe durchzuführen und vertrauliche Informationen aus anderen als seinen eigenen Anfragen zu erhalten.

Es sollte auch beachtet werden, dass der Anforderungsschmuggel in den letzten Monaten durch zahlreiche hochbezahlte Bug-Bounty-Berichte große Aufmerksamkeit in der Community erhalten hat, und Snyk stellte fest, dass im Jahr 2020 bisher 18 HTTP-Anforderungsschmuggel im Zusammenhang mit Abhängigkeiten veröffentlicht wurden.

Diese Sicherheitslücke wurde erstmals von Watchfire in ihrem Whitepaper aus dem Jahr 2005 mit dem Titel „Schmuggel von HTTP-Anfragen“. Diese Arbeit wurde später von Forschern erweitertRegis Leroyund weiter besprochen von James Kettle vom Portswigger-Sicherheitsdienst währendBlackHat USA 2019was weitere mediale Aufmerksamkeit erregte.

Ziel dieses Blogbeitrags ist es, die Schwachstelle zu entmystifizieren und Behebungsdetails für Open-Source-Projektbetreuer bereitzustellen, die den HTTP-Anforderungsschmuggel in ihren Projekten beheben möchten.

Hintergrund

Da neue Angriffe und Schwachstellen immer beliebter werden und in den Medien immer beliebter werden, geraten Open-Source-Bibliotheken häufig ins Visier von Angreifern, um sie in freier Wildbahn auszunutzen. Aufgrund mangelnder Behebungskenntnisse kann es oft Wochen oder Jahre dauern, bis diese Schwachstellen in diesen Bibliotheken ordnungsgemäß behoben werden. Um die Open-Source-Community sicher zu machen, führt das Snyk-Sicherheitsteam häufig Untersuchungen zu Schwachstellen durch, beispielsweise zum Schmuggel von HTTP-Anfragen, um Schwachstellen in Open-Source-Abhängigkeiten zu entdecken und den Betreuern umsetzbare Ratschläge zur Behebung zu geben.

Eine dieser Aufgaben wurde von Snyk übernommen, um die Auswirkungen des HTTP-Anforderungsschmuggels innerhalb des Open-Source-Abhängigkeitsökosystems zu ermitteln, was zur Entdeckung zahlreicher Schwachstellen führte. Weitere Informationen zu den entdeckten Schwachstellen finden Sie hierHier.

Snyk stellte fest, dass es nicht genügend öffentliche Quellen gibt, die geeignete Anleitungen zur Behebung des HTTP-Anforderungsschmuggels bieten. Darüber hinaus wurde festgestellt, dass die Betreuer mehrere Releases benötigten, um diese Schwachstelle ordnungsgemäß zu beheben und zu beheben. Mit diesem Blogbeitrag wollen wir diese Lücke schließen und jedem Betreuer, der Hilfe zu diesem Problem sucht, detaillierte Ratschläge zur Behebung geben.

Erklärung der Schwachstelle beim Schmuggel von HTTP-Anfragen

Um das HTTP-Request-Smuggling zu verstehen, müssen zunächst die folgenden Bereiche verstanden werden:

Keep-Alive und Pipelining

Das Konzept von Keep-Alive und Pipelining wurde ursprünglich in veröffentlichtRFC 2616.

Der Keep-Alive-Header ist ein Hop-by-Hop-Header, der Informationen über eine dauerhafte Verbindung bereitstellt. Bei Webservern kann Keep-Alive im „Connection“-Header angegeben werden, wodurch ein Webserver einen TCP-Socket/eine TCP-Verbindung offen halten kann. Durch die Verwendung dieses Headers können mehrere Anfragen und Antworten eine einzige Verbindung verwenden, was den Overhead reduzieren und die Leistung eines Webservers verbessern kann. Diese Funktion wird heute von allen Browsern und Servern unterstützt.

Pipelining ist eine weitere Funktion, die in RFC 2616 eingeführt wurde. Dadurch kann ein Webserver Anfragen asynchron verarbeiten – als First-In-First-Out-Stream, anstatt jede Anfrage einzeln zu verarbeiten, sodass er eine Anfrage senden kann, ohne auf das Eintreffen einer vorherigen Antwort warten zu müssen.

Inhaltslänge und Übertragungskodierung

HTTP-Anfragen können einen Nachrichtentext haben. Das Vorhandensein eines Nachrichtentexts in einer Anfrage wird durch ein Content-Length- oder Transfer-Encoding-Header-Feld signalisiert. Diese Header werden für das Nachrichten-Framing verwendet und teilen einem Server mit, wo eine Nachricht endet und eine andere beginnt.

Die Inhaltslänge, angegeben inRFC 7230, Abschnitt 3.3.2ist ein HTTP-Header, der die Größe des Entitätskörpers der Anfrage angibt. Dies tritt häufig bei HTTP-POST-Anfragen auf, die einen Datenkörper enthalten. Es ist zu beachten, dass GET-Anfragen normalerweise nicht den Content-Length-Header enthalten sollten, da sie keinen Hauptteil haben.

Transfer-Encoding, auch spezifiziert inRFC 7230wurde erstellt, um das Senden von Binärdaten über HTTP zu ermöglichen. Transfer-Encoding verfügt über zahlreiche Anweisungen. Dieser Blog konzentriert sich auf die Chunked-Anweisung.

Die Chunked-Direktive ermöglicht das Senden von Daten in aReihe von Brockenzusammen mitLänge dieser Stückeim Hexadezimalformat angegeben, gefolgt vonWagenrücklaufund einZeilenvorschub. Das Ende einer Chunked-Direktive wird durch angegeben0 und eine leere Sequenz. Ein Beispiel für eine Chunked-Anfrage ist unten zu sehen.

POST / HTTP/1.1Gastgeber:snyk.ioInhalt-Typ:Anwendung/X-www-form-urlcodiertÜberweisen-Codierung:gestückelt7(Länge von Brocken)foo=Bar(Serie von Brocken)0(0Zu beenden Anfrage gefolgt von rn)(rn)

Antrag auf Schmuggel

Ein moderner Webserver-Stack enthält häufig mehrere Webserver sowie Load Balancer und WSGI-Server. Ein einfaches Diagramm zur Visualisierung kann wie folgt aussehen:

Schwachstellen beim Schmuggel von HTTP-Anfragen entstehen, wenn das Frontend und das Backend die Grenze einer HTTP-Anfrage unterschiedlich interpretieren, was zu einer Desynchronisierung zwischen ihnen führt. Dies liegt daran, dass zahlreiche Frontend- und Backend-Bibliotheken von den RFC-Spezifikationen abweichen, wenn es um den Content-Length- und den Transfer-Encoding-Header geht. HTTP-Anforderungskörper können gemäß diesen beiden Headern gestaltet werden und es kann zu Abweichungen von der Spezifikation kommen. Dadurch wird ein Teil einer Anfrage an die nächste angehängt oder eingeschmuggelt, wodurch die Antwort auf die eingeschmuggelte Anfrage einem anderen Benutzer bereitgestellt werden kann.

Diese Schwachstelle kann ausgenutzt werden, um Phishing-Angriffe, Cache-Poisoning usw. durchzuführen.Cross-Site-Scripting (XSS), und mehr. Weitere Informationen zur Ausnutzung dieser Sicherheitslücke wurden letztes Jahr von James Kettle während der BlackHAT USA 2019 mit dem Titel „HTTP-Desync-Angriffe: Anforderungsschmuggel wiedergeboren“. Dieser Blog konzentriert sich auf die beiden häufigsten Techniken zum Schmuggel von Anfragen:

• CL:CL: Angriffstechnik mit doppelter Inhaltslänge

• CL:TE: Content-Length Transfer-

  Codierungsangriffstechnik

CL:CL: Angriffstechnik mit doppelter Inhaltslänge

EntsprechendRFC 7230, Abschnitt 3.3.3#4:

„Wenn eine Nachricht ohne Transfer-Encoding und mit mehreren Content-Length-Header-Feldern mit unterschiedlichen Feldwerten oder einem einzelnen Content-Length-Header-Feld mit einem ungültigen Wert empfangen wird, ist der Nachrichtenrahmen ungültig und der Empfänger MUSS ihn als nicht behebbaren Fehler behandeln”

Allerdings verarbeiten die meisten Middleware- und Webserver derzeit GET-Anfragen locker mit einem Textkörper. AußerdemRFC 7231, Abschnitt 4.3#4.3.1Zustände "Eine Nutzlast innerhalb einer GET-Anforderungsnachricht hat keine definierte Semantik; Das Senden eines Payload-Bodys bei einer GET-Anfrage kann dazu führen, dass einige vorhandene Implementierungen die Anfrage ablehnen“. Dies weist darauf hin, dass es sich um ein Verhalten handelt, das von den meisten Servern und Proxys unterstützt wird. In einigen Fällen kann dies zu Angriffen zum Schmuggel von Anfragen führen. In diesem Blog wird eine Variante dieses Angriffs untersucht.

GET / HTTP/1.1Inhaltslänge:43Inhaltslänge:0Gastgeber:snyk.ioERHALTEN/reqsmuggle HTTP/1.1Gastgeber:snyk.io

Wenn zwei Content-Length-Header bereitgestellt werden und Implementierungsunterschiede zwischen einem Frontend und einem Backend auftreten, bei dem der Content-Length-Header priorisiert werden soll, kann es zu Schmuggelangriffen kommen.

In der obigen HTTP-Anfrage wird eine Anfrage mit zwei Content-Length-Headern an ein Ziel gesendet, das über einen Proxy oder einen Load Balancer als Frontend verfügt. Der Proxy respektiert und priorisiert die erste Content-Length und betrachtet die eingeschleuste Anfrage als Teil des Anfragetexts, auch wenn eine GET-Anfrage keinen Anfragetext haben sollte und zwei Content-Length-Header bereitgestellt werden. Wenn dies vom Backend verarbeitet wird, wird der erste Content-Length-Header ignoriert und der zweite Content-Length-Header priorisiert. Da die zweite Content-Length auf Null gesetzt wurde, erwartet das Backend keinen Anfragetext und die/reqsmuggleDie Anfrage wird als eine weitere Pipeline-Anfrage behandelt. Daher könnte die Antwort auf diese geschmuggelte Anfrage von einem anderen Benutzer empfangen werden.

HTTP/1.1 200OKInhaltslänge:11Hallo WeltHTTP/1.1 404 NichtGefundenVerbindung:SchließenInhalt-Länge: 0

CL:TE: Content-Length Transfer-Encoding-Angriffstechnik

Diese beliebte Technik wurde von entdecktJames Kettle von den PortSwigger-LaborsDabei werden ein Content-Length-Header und ein Transfer-Encoding-Header in einer einzigen HTTP-Anfrage platziert und so manipuliert, dass ein Frontend-Proxy und ein Backend-Server diese Header priorisieren und die geschmuggelte Anfrage unterschiedlich verarbeiten. Eine Beispielanfrage, die diese Sicherheitslücke verdeutlicht, könnte wie folgt lauten.

POST /login HTTP/1.1Gastgeber:snyk.ioInhalt-Typ:Anwendung/X-www-form-urlcodiertInhalt-Länge: 62Überweisen-Codierung:gestückelt16Anmeldung=xxx&Passwort=xxx0ERHALTEN/404HTTP/1.1X-Foo:Bar

Wenn diese Anfrage von einem Frontend-Proxy verarbeitet wird, respektiert dieser den Content-Length-Header und priorisiert diesen vor dem Transfer-Encoding-Header. Der Backend-Server priorisiert jedoch den Transfer-Encoding-Header. Daher verarbeitet das Backend die Anfrage und endet beim Zeichen 0. Infolgedessen wird die 404-GET-Anfrage als separate Pipeline-Anfrage behandelt.

Dieses Problem tritt auf, weil das Frontend dem Content-Length-Header Vorrang vor dem Transfer-Encoding-Header einräumt. Gemäß RFC 7230 Abschnitt 3.3.3#3 überschreibt der Transfer-Encoding-Header die Content-Length, wenn eine Nachricht mit sowohl Content-Length als auch Transfer-Encoding akzeptiert wird. Darauf folgt nicht das Frontend.

In Fällen, in denen das Frontend den Transfer-Encoding-Header priorisieren könnte, kann diese Einschränkung möglicherweise umgangen werden, indem ein fehlerhafter Transfer-Encoding-Header anstelle eines gültigen eingefügt wird. Einige Beispiele hierfür sind unten zu sehen:

Übertragungskodierung: ChunkedÜBERTRAGUNGS-ENCODING: chunkedTransfer-Encoding: chunk

Zahlreiche HTTP-Bibliotheken tolerieren unterschiedliche Variationen des Transfer-Encoding-Headers und normalisieren diese, um das Client-Erlebnis zu verbessern. Wenn man also versteht, welche Variationen des Transfer-Encoding-Headers vom Backend-Server normalisiert werden, könnte es möglich sein, einen fehlerhaften Transfer-Encoding-Header über das Frontend zu schmuggeln und einen CL:TE-Schmuggelangriff durchzuführen.

Die obigen Beispiele verdeutlichen lediglich die Sicherheitslücke. In einem echten Angriffsszenario kann eine geschmuggelte Anfrage so gestaltet werden, dass sie Phishing-Angriffe ausführt oder Daten aus der Anfrage eines Opfers stiehlt und diese an einen vom Angreifer kontrollierten Server sendet.

Umfang und Missverständnisse

Während dieser Untersuchung identifizierte Snyk zahlreiche Fälle, in denen die offensichtliche Komplexität der vielfältigen Angriffsvektoren dazu führte, dass den Open-Source-Betreuern von Forschern und Betreuern falsche Vorstellungen über das Schmuggeln von HTTP-Anfragen gemeldet wurden, ohne immer zu verstehen, ob die Kriterien für die Behebung im Umfang ihrer gepflegten Bibliothek liegen oder ob es sich um eine Abhängigkeit handeln sollte, die sie als Teil ihrer Bibliothek verwenden.

Einige der Herausforderungen, die einer weiteren Klärung bedurften, sind folgende:

1. Proxys/Load Balancer und andere Medien, die als Frontend kategorisiert werden können, sind von dieser Schwachstelle am stärksten betroffen. Ein erfolgreicher Request-Smuggling-Angriff erfordert jedoch die Ausnutzung sowohl eines anfälligen Frontends als auch eines Backends.

2. Die Verantwortung für die Behebung liegt sowohl beim Backend-Betreuer als auch beim Frontend-Betreuer. Man kann argumentieren, dass die Normalisierung fehlerhafter Header ein akzeptables Verhalten eines Backends sein und es toleranter gegenüber Benutzerfehlern machen sollte, und dass das eigentliche Problem Proxys sind, die diese Anfragen weiterleiten, ohne sie vorher zu normalisieren. Aufgrund des riesigen Ökosystems an Abhängigkeiten und zahlreicher Bibliotheken, die die Kriterien eines Backends und eines Frontends erfüllen, ist es für beide Parteien ideal, zu versuchen, dieses Problem zu beheben.

3. Middlewares, Webserver, die Reverse-Proxy-Funktionen unterstützen, WSGI-/Hochleistungsserver gelten als den Backend-Kriterien entsprechend, nicht ein Webserver, der lediglich die Verarbeitung fehlerhafter Anforderungen, aber kein Pipelining unterstützt.

4. Sicherheitsberichte werden den Betreuern oft als Probleme beim Schmuggel von HTTP-Anfragen offengelegt, da Server auf mehrere gesendete Anfragen antworten und dies als zwei separate Antworten sichtbar ist. Es ist zu beachten, dass viele Server Keep-Alive und Pipelining unterstützen – dies allein stellt noch keine Schwachstelle für den Schmuggel von HTTP-Anfragen dar. Dies ist in CVE-2020-12440 der Fall, das für NGINX gemeldet wurde.

Sanierung

Aufgrund von Abweichungen von den aktuellen HTTP-Spezifikationen und mehreren Bibliotheken, die RFC7230 nicht befolgen, treten Probleme beim Schmuggel von HTTP-Anfragen auf. Darüber hinaus kann die Behebung dieser Schwachstelle schwierig sein, je nachdem, ob Sie Frontend- oder Backend-Projektbetreuer sind. Daher hat Snyk die derzeit von Open-Source-Projekten durchgeführten Abhilfemaßnahmen untersucht und sie wie folgt kategorisiert. Zur Vereinfachung werden alle Abhilfemaßnahmen abgedeckt und erläutert, gegen welche Schmuggelangriffsart Abhilfe geschaffen wird. Im Idealfall sollten alle unten genannten Punkte genutzt werden, um eine Defense-in-Depth-Ansatzlösung bereitzustellen.

Transfer-Encoding vor Content-LengthRemediation priorisieren:Durch diese Abhilfe werden CL:TE- und TE:CL-Angriffe verhindertUmfang:Frontend, BackendEinzelheiten:Wenn eine Anfrage mit einem Transfer-Encoding: Chunked-Header und Content-Length empfangen wird, sollte der Transfer-Encoding-Header Vorrang vor Content-Length haben. Darauf wird in RFC 7230 Abschnitt 3.3.3#3 verwiesen.

Anfragen mit Content-Length- und Transfer-Kodierung sowie doppelten Content-Length-Headern nicht zulassen. Abhilfe:Durch diese Abhilfe werden CL:CL-, CL:TE- und TE:CL-Angriffe verhindertUmfang:Backend, Frontend, Backend, Upstream-BibliothekenEinzelheiten:Dies kann als bessere Alternative zur Lösung „Priorität der Übertragungskodierung gegenüber der Inhaltslänge“ angesehen werden. Laufzeitplattformen wie Node.js haben diese Lösung verwendet, um dem Anforderungsschmuggel vorzubeugen, bei dem alle Anforderungen mit beiden Headern mit einer HTTP 400-Antwort zurückgegeben werden.

Snyk glaubt, dass diese Technik eine ideale Lösung ist, um Schmuggelproblemen vorzubeugen. Es sollten jedoch Überlegungen zur Anwendung des Fixes angestellt werden. insbesondere, wenn der Fix auf eine Low-Level-HTTP-Bibliothek oder eine Upstream-Engine angewendet wird, von der zahlreiche Pakete, wie zum Beispiel ein Frontend, abhängen.

Bei der Behebung von HTTP-Request-Smuggling-ProblemenRFC 7230 #3.3.3sollte befolgt werden.Abschnitt 3.3.3#3In RFC 7230 heißt es:

„Wenn eine Nachricht sowohl mit einem Transfer-Encoding- als auch einem Content-Length-Header-Feld empfangen wird, überschreibt das Transfer-Encoding das Content-Length. Eine solche Nachricht könnte auf einen Versuch hindeuten, eine Anfrage zu schmuggeln (Abschnitt 9.5) oder eine Antwort aufzuteilen (Abschnitt 9.4) und sollte als Fehler behandelt werden. Ein Absender MUSS das empfangene Content-Length-Feld entfernen, bevor er eine solche Nachricht weiterleitet.“

Dies unterscheidet sich jedoch von dem, was darin angegeben istRFC 2616 4.4#3:

„Wenn eine Nachricht sowohl mit einem Transfer-Encoding-Header-Feld als auch einem Content-Length-Header-Feld empfangen wird, MUSS letzteres ignoriert werden.“

Es ist darauf hinzuweisen, dassRFC 2616 4.4#3ist veraltet und wurde durch ersetztRFC 7230.RFC 7230sollten bei der Implementierung eines Fixes berücksichtigt werden. Wenn HTTP-Anfragen sowohl mit einem Content-Length- als auch einem Transfer-Codierungsheader verarbeitet werden, besteht das korrekte Verhalten hier darin, dass das Frontend den Content-Length-Header entfernen sollte, bevor die Anfrage an ein Downstream-Backend weitergeleitet wird, und keinen HTTP 400-Antwortheader zurückgibt. Dasselbe sollte für Anfragen mit mehreren Content-Length-Headern durchgeführt werden, wie in angegebenRFC 7230#3.3.2.

Wie in RFC 7230 Abschnitt 3.3.2 erwähnt, kann der Empfang einer HTTP-Anfrage mit mehreren Content-Length-Headern mit unterschiedlichen Längenwerten durch eine HTTP 400-Antwort behoben werden, oder die doppelten Feldwerte sollten durch ein einzelnes gültiges Content-Length-Feld ersetzt werden. Snyk empfiehlt Low-Level-HTTP-Bibliotheken, mehrere Header durch einen einzigen gültigen Header zu ersetzen.

Verbieten Sie fehlerhafte Transfer-Encoding-Header und korrigieren Sie die Verarbeitung mehrerer TE-Werte. Abhilfe:Durch diese Abhilfe werden TE:TE-Angriffe verhindert.Umfang:Frontend, BackendEinzelheiten:Wenn sowohl ein Frontend als auch ein Backend den Transfer-Encoding-Header priorisieren, könnte dies Schmuggelangriffe ermöglichen, bei denen ein Angreifer zwei Transfer-Encoding-Header einfügt, von denen einer vom Frontend ignoriert und vom Backend verarbeitet wird und umgekehrt. Daher sollten die folgenden Arten von Header-Variationen abgelehnt werden.

Es ist jedoch zu beachten, dass es für Angreifer immer noch möglich ist, eine fehlerhafte Header-Variante der „Chunked“-Codierung zu finden, die oben nicht dokumentiert ist. Daher sollte dies allein bei der Sanierung nicht berücksichtigt werden. Ein besserer Ansatz wäre, Anfragen mit Content-Length und Transfer-Encoding sowie fehlerhafte Header nicht zuzulassen.

Abschließend sollte auch beachtet werden, dass, wenn der „Chunked“-Wert zusammen mit anderen Transfer-Encoding-Werten wie „gzip“ oder „deflate“ angegeben wird, dieser nicht übersehen werden sollte und Transfer-Encoding Vorrang vor Content-Length haben sollte. Ein Beispiel für das Auftreten dieser Sicherheitslücke finden Sie in CVE-2019-16786. Wenn eine HTTP-Anfrage mit den folgenden Transfer-Encoding-Werten gesendet wird, sollte der „Chunked“-Wert korrekt identifiziert und priorisiert werden:

Übertragungskodierung: gzip, chunked

Innerhalb eines Transfer-Encoding-Headers können mehrere Werte durch Komma getrennt aufgelistet werden. Es kann jedoch vorkommen, dass ein Frontend nur den „gzip“-Wert identifiziert und daher den Content-Length-Header priorisiert und das Backend dies als geblockte Anfrage verarbeitet, was zu einem CL:TE-Angriff führt. Snyk empfiehlt, immer dann, wenn mehrere Werte angegeben werden, diese korrekt zu überprüfen und, wenn „chunked“ angegeben ist, der Transfer-Encoding Vorrang einzuräumen. Wenn außerdem mehrere Transfer-Codierungs-Header angegeben werden, sollte der „chunked“-Wert nur als letzter Wert vorhanden sein, nachdem andere Transfer-Codierungswerte angegeben wurden. Dies ist in angegebenRFC 7230 Abschnitt 3.3.1.

Einpacken

Zusammenfassend lässt sich sagen, dass der Schmuggel von HTTP-Anfragen eine verwirrende Schwachstelle sein kann, die es zu verstehen und zu beheben gilt. Dieser Blog soll Betreuern dabei helfen, effiziente Patches zu schreiben und ihre Open-Source-Projekte zu sichern.

Es ist auch erwähnenswert, dass dieser Blogbeitrag nur zwei Techniken des HTTP-Anforderungsschmuggels behandelt und keine detaillierten Informationen zu verschiedenen Ausnutzungsszenarien liefert. Der folgende Artikel des Sicherheitsforschers ZeddYu hat sich ausführlich mit dem Schmuggel von HTTP-Anfragen befasst und detaillierte Details zu jedem Angriffsschmuggel-Vektor bereitgestellt:Zeddy Yu: Hilft Ihnen, HTTP-Schmuggel in einem Artikel zu verstehen.