Une attaque contre les systèmes front-end-back-end qui nous permet de nous coincer dans les requêtes de tiers

Divulguée les détails d'une nouvelle attaque contre des sites qui utilisent un modèle front-end-back-end, tels que ceux fonctionnant via des réseaux de diffusion de contenu, des équilibreurs de charge ou des proxys. L'attaque permet, en envoyant certaines requêtes, de se caler sur le contenu d'autres requêtes traitées dans le même thread entre le frontend et le backend. La méthode proposée a été utilisée avec succès pour organiser une attaque permettant d'intercepter les paramètres d'authentification des utilisateurs du service PayPal, qui a payé aux chercheurs environ 40 XNUMX dollars dans le cadre d'un programme visant à informer de la présence de vulnérabilités non corrigées. L'attaque s'applique également aux sites utilisant le réseau de diffusion de contenu d'Akamai.

Le nœud du problème est que les frontends et les backends fournissent souvent différents niveaux de prise en charge du protocole HTTP, mais encapsulent en même temps les requêtes des différents utilisateurs dans un canal commun. Pour connecter les requêtes de réception frontend et les requêtes de traitement backend, une connexion TCP de longue durée est établie, à travers laquelle les requêtes des utilisateurs sont transmises, transmises le long de la chaîne les unes après les autres, séparées au moyen du protocole HTTP. Pour séparer les requêtes, les en-têtes "Content-Length" (détermine la taille totale des données dans la requête) et "Transfer-Encoding: chunked"(vous permet de transférer des données par parties, en spécifiant des blocs de différentes tailles au format "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Le problème survient si le frontend ne prend en charge que « Content-Length » mais ignore « Transfer-Encoding : chunked » (par exemple, Akamai CDN l'a fait) ou vice versa. Si Transfer-Encoding: chunked est pris en charge des deux côtés, les fonctionnalités d'implémentation des analyseurs d'en-tête HTTP peuvent être utilisées pour une attaque (par exemple, lorsque le frontal ignore des lignes telles que « Transfer-Encoding : xchunked », « Transfer-Encoding : chunked »). ”, “Transfer-Encoding” :[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" ou "Transfer-Encoding : chunked", et le backend les traite avec succès).

Dans ce cas, un attaquant peut envoyer une requête contenant à la fois les en-têtes « Content-Length » et « Transfer-Encoding: chunked », mais la taille dans « Content-Length » ne correspond pas à la taille de la chaîne chunked, ce qui est inférieure à la valeur réelle. Si le frontend traite et transmet la demande en fonction de « Content-Length » et que le backend attend que le bloc soit terminé en fonction de « Transfer-Encoding : chunked », alors la fin des données basée sur « Transfer-Encoding : chunked » sera être déterminé plus tôt et la fin restante de la requête, l'attaquant sera au début de la requête suivante, c'est-à-dire l'attaquant pourra joindre des données arbitraires au début de la requête de quelqu'un d'autre transmise ensuite.

Pour déterminer le problème dans la combinaison frontend-backend utilisée, vous pouvez envoyer une requête comme celle-ci via le frontend :

POST /à propos de HTTP/1.1
Hébergeur : example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Le problème est présent si le backend ne traite pas immédiatement la demande et attend l'arrivée du dernier bloc de délimitation zéro des données fragmentées. Pour un contrôle plus complet préparé par un utilitaire spécial qui teste également les méthodes possibles pour masquer l'en-tête « Transfer-Encoding: chunked » du frontend.

Réaliser une véritable attaque dépend des capacités du site attaqué, par exemple, lors d'une attaque contre l'application web Trello, vous pouvez remplacer le début de la requête (remplacer les données comme « PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake") et envoyer un message comprenant la demande originale d'un utilisateur tiers et le Cookie d'authentification qui y est spécifié. Pour une attaque sur saas-app.com, il s'est avéré possible de substituer du code JavaScript dans la réponse en le substituant dans l'un des paramètres de la requête. Pour l’attaque sur redhat.com, un gestionnaire interne a été utilisé pour rediriger vers le site Web de l’attaquant (une requête du type « POST /search?dest=../assets/idx?redir=//[email protected]/HTTP/1.1").

L'utilisation de la méthode des réseaux de diffusion de contenu a permis de remplacer simplement le site demandé en substituant l'en-tête « Host : ». L’attaque peut également être utilisée pour empoisonner le contenu des systèmes de mise en cache de contenu et extraire des données confidentielles mises en cache. Le summum de la méthode a été l'organisation d'une attaque sur PayPal, qui a permis d'intercepter les mots de passe envoyés par les utilisateurs lors de l'authentification (la requête iframe a été modifiée pour exécuter du JavaScript dans le contexte de la page paypal.com/us/gifts, par exemple quel CSP (Content Security Policy) n’a pas été appliqué).

Il est intéressant de noter qu'en 2005, il y a eu proposé une technique d'usurpation de requête essentiellement similaire qui vous permet d'usurper les données dans les proxys de mise en cache (Tomcat, squid, mod_proxy) ou de contourner le blocage du pare-feu en spécifiant plusieurs requêtes « GET » ou « POST » au sein d'une même session HTTP.

Source: opennet.ru