Ein Angriff auf Front-End-Back-End-Systeme, der es uns ermöglicht, in Anfragen Dritter einzudringen

Offengelegt Details zu einem neuen Angriff auf Websites, die ein Front-End-Back-End-Modell verwenden, beispielsweise solche, die über Content-Delivery-Netzwerke, Load Balancer oder Proxys laufen. Der Angriff ermöglicht es, sich durch das Senden bestimmter Anfragen in den Inhalt anderer Anfragen einzuschleichen, die im selben Thread zwischen Frontend und Backend verarbeitet werden. Mit der vorgeschlagenen Methode wurde erfolgreich ein Angriff organisiert, der es ermöglichte, die Authentifizierungsparameter von Benutzern des PayPal-Dienstes abzufangen, der den Forschern im Rahmen eines Programms zur Information über das Vorhandensein ungepatchter Schwachstellen etwa 40 Dollar zahlte. Der Angriff ist auch auf Websites anwendbar, die das Akamai-Content-Delivery-Netzwerk nutzen.

Der Kern des Problems besteht darin, dass Frontends und Backends häufig unterschiedliche Unterstützungsstufen für das HTTP-Protokoll bereitstellen, gleichzeitig jedoch Anfragen verschiedener Benutzer in einem gemeinsamen Kanal kapseln. Um die empfangenden Frontend-Anfragen und die verarbeitenden Backend-Anfragen zu verbinden, wird eine langlebige TCP-Verbindung hergestellt, über die Benutzeranfragen nacheinander entlang der Kette übertragen werden, getrennt durch das HTTP-Protokoll. Um Anfragen zu trennen, werden die Header „Content-Length“ (bestimmt die Gesamtgröße der Daten in der Anfrage) und „Transfer-Encoding: Chunked„(ermöglicht die Übertragung von Daten in Teilen, indem Blöcke unterschiedlicher Größe im Format „{size}\r\n{block}\r\n{size}\r\n{block}\r\n0“ angegeben werden).

Das Problem entsteht, wenn das Frontend nur „Content-Length“ unterstützt, aber „Transfer-Encoding: chunked“ ignoriert (das hat beispielsweise Akamai CDN getan) oder umgekehrt. Wenn Transfer-Encoding: chunked auf beiden Seiten unterstützt wird, können die Implementierungsfunktionen von HTTP-Header-Parsern für einen Angriff genutzt werden (z. B. wenn das Frontend Zeilen wie „Transfer-Encoding: xchunked“, „Transfer-Encoding: chunked “, „Transfer-Encoding“ :[tab]chunked“, „X: das Backend verarbeitet sie erfolgreich).

In diesem Fall kann ein Angreifer eine Anfrage senden, die sowohl die Header „Content-Length“ als auch „Transfer-Encoding: chunked“ enthält, die Größe in „Content-Length“ jedoch nicht der Größe der Chunked-Kette entspricht ist kleiner als der tatsächliche Wert. Wenn das Frontend die Anfrage gemäß „Content-Length“ verarbeitet und weiterleitet und das Backend basierend auf „Transfer-Encoding: chunked“ auf den Abschluss des Blocks wartet, dann erfolgt das Ende der Daten basierend auf „Transfer-Encoding: chunked“. früher bestimmt werden und der verbleibende Schwanz der Anfrage wird vom Angreifer am Anfang der nächsten Anfrage stehen, d. h. Der Angreifer kann beliebige Daten an den Anfang der als nächstes übermittelten Anfrage einer anderen Person anhängen.

Um das Problem in der verwendeten Frontend-Backend-Kombination zu ermitteln, können Sie über das Frontend eine Anfrage wie diese senden:

POST /über HTTP/1.1
Host: example.com
Transfer-Encoding: Chunked
Content-Length: 4

1
Z
Q

Das Problem liegt vor, wenn das Backend die Anfrage nicht sofort verarbeitet und auf die Ankunft des letzten Null-Begrenzungsblocks mit Chunked-Daten wartet. Für eine umfassendere Überprüfung vorbereitet von ein spezielles Dienstprogramm, 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 Fähigkeiten der angegriffenen Site ab. Wenn Sie beispielsweise die Trello-Webanwendung angreifen, können Sie den Anfang der Anfrage ersetzen (Ersatzdaten wie „PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake“) und senden Sie eine Nachricht mit der ursprünglichen Anfrage eines Drittbenutzers und dem darin angegebenen Authentifizierungs-Cookie. Bei einem Angriff auf saas-app.com erwies es sich als möglich, JavaScript-Code in der Antwort zu ersetzen, indem man ihn in einem der Anforderungsparameter ersetzte. Für den Angriff auf redhat.com wurde ein interner Handler verwendet, um auf die Website des Angreifers umzuleiten (eine Anfrage der Form „POST /search?dest=../assets/idx?redir=//[E-Mail geschützt] /HTTP/1.1").

Die Verwendung der Methode für Content-Delivery-Netzwerke ermöglichte es, die angeforderte Site einfach durch Ersetzen des „Host:“-Headers zu ersetzen. Der Angriff kann auch dazu verwendet werden, den Inhalt von Content-Caching-Systemen zu vergiften und zwischengespeicherte vertrauliche Daten zu extrahieren. Der Höhepunkt der Methode war die Organisation eines Angriffs auf PayPal, der es ermöglichte, von Benutzern während der Authentifizierung gesendete Passwörter abzufangen (die Iframe-Anfrage wurde geändert, um JavaScript im Kontext der Seite paypal.com/us/gifts auszuführen, z welches CSP (Content Security Policy) nicht angewendet wurde).

Interessanterweise gab es das im Jahr 2005 vorgeschlagen eine im Wesentlichen ähnliche Anfrage-Spoofing-Technik, die es Ihnen ermöglicht, Daten in Caching-Proxys (Tomcat, Squid, Mod_Proxy) zu fälschen oder die Firewall-Blockierung zu umgehen, indem Sie mehrere „GET“- oder „POST“-Anfragen innerhalb einer HTTP-Sitzung angeben.

Source: opennet.ru