Angriff auf Frontend-Backend-Systeme, der es ermöglicht, in externe Anfragen einzudringen

Enthüllt Details eines neuen Angriffs auf Websites, die das Frontend-Backend-Modell nutzen, z. B. solche, die über Content Delivery Networks, Lastenausgleicher oder Proxys arbeiten. Der Angriff ermöglicht es, durch das Senden bestimmter Anfragen in den Inhalt anderer Anfragen einzugreifen, die im selben Stream zwischen Frontend und Backend verarbeitet werden. Die vorgeschlagene Methode wurde erfolgreich zur Durchführung eines Angriffs eingesetzt, der es erlaubt, die Authentifizierungsparameter von Benutzern des Dienstes PayPal abzufangen, der den Forschern im Rahmen eines Programms zur Meldung unbehobener Sicherheitsanfälligkeiten etwa 40.000 Dollar ausgezahlt hat. Der Angriff ist auch für Websites anwendbar, die das Content Delivery Network Akamai verwenden.

Das Problem besteht darin, dass Frontends und Backends oft unterschiedliche Unterstützung für das HTTP-Protokoll bieten, während sie gleichzeitig die Anfragen verschiedener Benutzer in einen gemeinsamen Kanal kapseln. Es wird eine langanhaltende TCP-Verbindung zwischen dem anfragenden Frontend und dem verarbeitenden Backend eingerichtet, über die die Benutzeranfragen in einer Kette, nacheinander, mit Hilfe des HTTP-Protokolls übertragen werden. Zur Trennung der Anfragen können die Header „Content-Length“ (definiert die Gesamtgröße der Daten in der Anfrage) und „Transfer-Encoding: chunked“ (erlaubt das Übertragen von Daten in Teilen, indem Blöcke unterschiedlicher Größe im Format „{Größe}\r\n{Block}\r\n{Größe}\r\n{Block}\r\n0“ angegeben werden).

Das Problem tritt auf, wenn das Frontend nur „Content-Length“ unterstützt, aber „Transfer-Encoding: chunked“ ignoriert (zum Beispiel handelte es sich so beim CDN Akamai) oder umgekehrt. Im Falle der Unterstützung von „Transfer-Encoding: chunked“ auf beiden Seiten können die Besonderheiten der Implementierungen der HTTP-Header-Parser für den Angriff genutzt werden (z. B. wenn das Frontend Zeilen wie „Transfer-Encoding: xchunked“, „Transfer-Encoding: chunked“, „Transfer-Encoding:[tab]chunked“, „X: X[\n]Transfer-Encoding: chunked“, „Transfer-Encoding[\n]: chunked“ oder „Transfer-Encoding : chunked“ ignoriert und das Backend diese erfolgreich verarbeitet).

In diesem Fall kann der Angreifer eine Anfrage senden, in der sowohl die Header "Content-Length" als auch "Transfer-Encoding: chunked" angegeben sind, jedoch die Größe in "Content-Length" nicht der Größe der chunked-Kette entspricht, die kleiner ist als der tatsächliche Wert. Wenn das Frontend die Anfrage gemäß "Content-Length" verarbeitet und umleitet, das Backend jedoch auf den endgültigen Block basierend auf "Transfer-Encoding: chunked" wartet, wird das Ende der Daten basierend auf "Transfer-Encoding: chunked" früher bestimmt, und der verbleibende Rest der Anfrage des Angreifers wird am Anfang der nächsten Anfrage erscheinen, d.h. der Angreifer erhält die Möglichkeit, beliebige Daten an den Anfang einer fremden Anfrage anzuhängen, die anschließend gesendet wird.

Um das Problem in der verwendeten Frontend-Backend-Bindung zu bestimmen, kann durch das Frontend eine Anfrage wie folgt gesendet werden:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Das Problem besteht, wenn das Backend die Anfrage nicht sofort verarbeitet und auf den Empfang des finalen nullterminierenden Blocks der chunked-Daten wartet. Für eine umfassendere Überprüfung wurde vorbereitet ist ein spezielles Tool erforderlich, das auch mögliche Methoden testet, um den Header "Transfer-Encoding: chunked" vor dem Frontend zu verbergen.

Die Durchführung eines echten Angriffs hängt von den Möglichkeiten der angegriffenen Website ab. Zum Beispiel konnte beim Angriff auf die Webanwendung Trello der Anfang der Anfrage (Daten wie "PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake" eingeben) geändert werden, und eine Nachricht gesendet werden, die die originale Anfrage eines anderen Benutzers und die darin enthaltenen Authentifizierungscookies einsetzt. Für den Angriff auf saas-app.com war es möglich, JavaScript-Code in die Antwort einzufügen, indem er in einen der Anfrageparameter eingefügt wurde. Für den Angriff auf redhat.com wurde ein interner Handler verwendet, um auf die Seite des Angreifers umzuleiten (eine Anfrage wie "POST /search?dest=../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1" wurde eingefügt).

Die Anwendung der Methode für Content Delivery Networks ermöglichte es, die angeforderte Website einfach durch das Ersetzen des "Host:"-Headers zu ändern. Der Angriff ist auch anwendbar, um Inhalte in Caching-Systemen zu vergiften und zwischengespeicherte vertrauliche Daten zu extrahieren. Der Höhepunkt der Anwendung dieser Methode war ein Angriff auf PayPal, der es ermöglichte, Passwörter abzufangen, die von Benutzern bei der Authentifizierung gesendet wurden (es wurde eine Änderung der iframe-Anfrage vorgenommen, um JavaScript im Kontext der Seite paypal.com/us/gifts auszuführen, für die keine CSP (Content Security Policy) galt).

Interessanterweise gab es im Jahr 2005 eine wurde vorgeschlagen ähnliche Technik zur Änderung von Anfragen, die es ermöglichte, Daten in Caching-Proxys (Tomcat, squid, mod_proxy) zu ändern oder Firewall-Beschränkungen zu umgehen, indem mehrere "GET"- oder "POST"-Anfragen innerhalb eines HTTP-Sitzung angegeben wurden.

Quelle: opennet.ru