👍 💆🏻 ⛱️ Sécurité grâce à la restriction des utilisateurs ou comment créer une vulnérabilité 👨🏾‍🔬 🐳 👩🏾‍🚀

En 2019, la vulnérabilité CPDoS Cache Poisoned Denial of Service) a été découverte sur le réseau CDN, ce qui permet d'empoisonner le cache HTTP du fournisseur CDN et de provoquer un déni de service. La vulnérabilité n'a pas encore recueilli beaucoup de battage médiatique, car elle n'a pas été vue dans de vraies attaques. Mais je veux parler séparément d'une des méthodes d'empoisonnement du cache. Substitution de méthode HTTP.

Si d'autres variantes d'exploitation de la vulnérabilité d'une manière ou d'une autre s'appuient sur des bogues ou des fonctionnalités de modification de demande par un intermédiaire, alors la variante de substitution de méthode est basée sur la tactique du même nom, qui ne fait pas partie de la norme HTTP, entraîne des problèmes supplémentaires, et qui sont survenus et se sont propagés en raison d'une négligence relation avec la sécurité. Ici, nous allons l'examiner.

Bref sur CPDoS si vous l'avez manqué

, URI method .

, , , , - . — - - -, , - , . , .

, . , , -. - , , .

Limitez le client, moins peut - moins se cassera

Le besoin même de remplacer la méthode dans la demande est dû au fait que certains pare-feu d'application Web et implémentations client HTTP étaient très limités et ne permettaient pas l'exécution de méthodes autres que GET et POST. Le problème n'est pas qu'il s'agissait d'une restriction d'implémentation, mais qu'il s'agissait d'une restriction intentionnelle des clients HTTP par une politique de sécurité.

Il est clair que tout a été réalisé avec la bonne intention de couper le trafic exigu, non standard pour les clients HTTP ordinaires. Mais dans un souci de sécurité, toutes les méthodes sauf GET et POST ont été supprimées. Peut-être parce que ce sont les seules méthodes qui ne sont pas facultatives et requises pour les serveurs à usage général.

La raison pour laquelle il était nécessaire d'introduire une restriction aussi stricte n'est pas claire. Oui, les attaques avec l'introduction de différents caractères afin de confondre l'analyseur ne sont que le passe-temps des protocoles de texte. Mais vous pouvez autoriser un peu plus de méthodes, par exemple, prendre au moins celles qui sont décrites dans la norme elle-même ou enregistrées auprès de l'IANA . Cela ne valait pas la peine de supprimer complètement la vérification des méthodes, mais vous pouvez composer un certain nombre des méthodes les plus populaires et en exclure celles qui modifient le protocole d'interaction et interrompent le travail avec les connexions sur le serveur proxy (CONNECT). Mais non, il s'est avéré une politique de sécurité qui a introduit des restrictions et des interdictions inutiles pour les clients.

Et les clients étaient limités aux mauvais. Ils voulaient limiter la variabilité des messages des clients HTTP et limitaient les clients protégés par ces WAF, les serveurs d'applications finaux et leurs développeurs. Désormais, les développeurs n'avaient plus que deux méthodes qui n'étaient pas toujours suffisantes pour décrire la logique du client HTTP.

Des contraintes sont créées pour les surmonter.

Il était à prévoir que cette restriction excessive commencerait tôt ou tard à interférer avec les développeurs Web. L'ironie est qu'il est si facile de ne pas se débarrasser de ces WAF. Surtout quand ils sont avec des clients ou des fournisseurs. Remettre en question les politiques de sécurité des autres est une affaire désastreuse.

En raison de la flexibilité de HTTP, il n'est pas difficile de contourner cette limitation; ajoutez simplement quelque chose à la demande où vous pouvez remplacer la méthode. Strict WAF vérifiera uniquement la méthode dans la ligne de demande (la première ligne de la demande) et sera heureux de voir un GET ou POST approuvé là-bas. Et le backend pourra analyser l'élément ajouté et en extraire la vraie méthode.

Vous pouvez google un tas d' articles, vraiment un tassur la façon dont les proxys défectueux ont brisé les applications REST, et comment les auteurs ont dû passer la vraie méthode dans un en-tête séparé. Dans chacun d'eux, ils suggèrent que vous saisissiez approximativement le même en-tête (méthode X-HTTP, méthode X-HTTP-Override ou méthode X-Override - l'orthographe varie quelque peu) pour indiquer une méthode remplacée. Très, très rarement, on peut trouver des références qui peuvent être utilisées pour le même objet URI de composant de requête.

Ce qui manque dans ces articles, c'est la section Considérations sur la sécurité. Et ils le sont.

La méthode est-elle sûre?

Parfois, les développeurs d'applications Web oublient qu'entre le client et le serveur, il peut y avoir des participants intermédiaires qui interagissent via le protocole HTTP: mandataires, caches Web des fournisseurs, CDN et WAF. La prolifération de TLS réduit considérablement les chances d'un participant intermédiaire entre le client et le serveur. Le seul proxy entre le client et le backend sera probablement son propre serveur avec Nginx. Et une telle configuration est assez facile à tester sur des scénarios typiques avant sa sortie.

Mais nous entrons dans l'ère du CDN, et de plus en plus d'applications se cacheront derrière les CDN qui lisent et manipulent le trafic des utilisateurs. Les backends ne servent presque jamais directement les utilisateurs et se cachent derrière des proxys inversés pour augmenter la réactivité et les performances. Par conséquent, vous devrez vous rappeler comment le remplacement d'une méthode peut affecter le traitement d'une demande sur un serveur de médiation.

Les attaques dont je veux parler s'appliquent principalement à HTTP / 1.1. HTTP / 2 hérite en quelque sorte du comportement de l'ancienne norme, à certains égards suit sa propre voie, donc l'applicabilité de chaque attaque à la nouvelle norme sera considérée séparément.

Attaques de cache

Le plus souvent, les serveurs intermédiaires ne prennent pas en compte les remplacements de méthode, ne vérifient pas les en-têtes de la famille X-HTTP-Method-Override et travaillent avec la demande en utilisant sa méthode principale à partir de la ligne de demande. Et puisque la méthode remplacée n'est pas incluse dans la clé pour rechercher une demande dans le cache (méthode + URI), ces serveurs ne peuvent pas distinguer POST de POST + X-HTTP-Method-Override: DELETE. Cela signifie que vous ne pouvez pas autoriser la mise en cache des requêtes vers un certain URI si le backend peut surveiller et exécuter des méthodes remplacées.

Le document CPDoS a un bon exemple de ce qui se passe si vous mettez en cache une telle demande. Lorsqu'un attaquant déguise une demande POST en demande GET, le proxy ne reconnaît pas les substitutions et traite la demande comme une demande GET légitime. Le backend, cependant, reconnaît la méthode substituée et exécute le verbe décrit dans l'en-tête X-HTTP-Method-Override - POST. Étant donné que la méthode POST n'est pas définie pour l'URI de destination, le serveur génère une erreur. En outre, la réponse de backend est stockée dans le cache en tant que réponse à la méthode d'origine - GET. Maintenant, toute prochaine requête GET pour le même URI retournera une erreur mise en cache.

En fait, l'attaque est légèrement plus large que celle présentée dans le document. Les auteurs se sont concentrés sur le stockage de l'erreur dans le cache, qui n'est pas partout (déjà) reproductible. Mais si la méthode demandée pour l'URI sélectionné est définie et sera exécutée avec succès, le proxy recevra une réponse avec un état de 200 et la mettra en cache. Ensuite, les demandes suivantes du même URI pour recevoir des réponses à la méthode complètement erronée. Dans ce scénario, il n'y a plus d'exigence avec une erreur de cache de réponses 4XX, comme dans la description CPDoS d'origine.

Le problème inverse peut se produire. Si un client HTTP respectable envoie une demande GET + X-HTTP-Method-Override: PATCH (c'est mauvais, mais plus à ce sujet plus tard), et le cache a déjà une réponse GET, alors le client recevra cette réponse en cache. Dans ce cas, le backend ne recevra jamais de demande PATCH, ce qui peut violer la logique d'application sur le client et le serveur.

Vous pouvez réduire l'effet sur le cache en créant les stratégies de mise en cache correctes et en divisant les ressources en deux groupes: ceux pour lesquels l'opération de substitution de méthode est inacceptable ou non requis, les réponses à ceux-ci peuvent être mises en cache et celles pour lesquelles l'opération de remplacement de méthode est nécessaire, toute mise en cache de ces réponses est inacceptable . Mais moins les ressources sont mises en cache, moins le CDN est utile et plus le trafic atteint le backend, plus l'application est exposée au déluge HTTP.

Par conséquent, il est préférable d'utiliser le cache HTTP autant que possible, pour cela, il est nécessaire que le serveur de cache puisse distinguer les demandes avec différentes méthodes remplacées. La première façon consiste à transférer le remplacement de méthode du composant de requête vers l'URI:

POST /some-uri HTTP/1.1
X-HTTP-Method-Override: DELETE
   ↓  ↓   ↓
POST /some-uri?method=DELETE HTTP/1.1

Désormais, les requêtes avec différentes méthodes sont différentes pour le cache, car elles obtiennent des clés différentes. Certains mandataires préfèrent ne pas mettre en cache les réponses aux demandes contenant le composant de requête dans l'URI. Mais cela n'affectera que l'efficacité de la mise en cache. Cette méthode résout toujours les problèmes de mise en cache incorrecte.

Une autre façon consiste à laisser la méthode remplacer dans un en-tête séparé, mais entrez une clé secondaire pour trouver la réponse dans le cache. Cela est possible avec l'en-tête Vary. Lors du traitement de la demande, le serveur répétera l'en-tête avec la méthode override et reflétera le nom de cet en-tête dans l'en-tête Vary. Ensuite, aux demandes suivantes, le serveur de cache utilisera la valeur de la méthode remplacée comme clé secondaire lors de la recherche d'une demande dans le cache.

Cette méthode fonctionne si le serveur intermédiaire peut fonctionner avec des clés secondaires. C'est généralement le cas, mais le niveau de confiance du proxy, qui coupe toutes les méthodes sauf GET et POST, est généralement plus bas et il est préférable de le vérifier.

Remplacer une méthode par le biais de n'importe quelle entité à l'intérieur du corps de la demande présente exactement les mêmes inconvénients que le remplacement par un en-tête supplémentaire - cela est hors de la visibilité du cache.

Attaques Message Queuing

Même si les attaques de cache sont fermées, ce n'est pas tout. Un attaquant en redéfinissant une méthode peut essayer de modifier le cadrage de la réponse et ainsi violer la correspondance des paires requête-réponse pour les autres clients. Ou forcez le côté serveur de l'application à traiter plusieurs fois la même demande.

La chose la plus importante qui est requise pour cela est un serveur intermédiaire fonctionnant en mode proxy inverse. Autrement dit, tout serveur de mise en cache ou CDN. Un tel proxy prend en charge un nombre relativement faible de connexions au backend et multiplie les demandes de nombreux clients dans chacun d'eux. Cela est nécessaire à la fois pour prendre la charge de la prise en charge d'un grand nombre de connexions clientes des backends vers le serveur proxy et pour équilibrer la charge entre les backends. La terminaison des connexions TLS se produit également sur le proxy, les connexions client ne sont jamais connectées directement au backend.

Étant donné que maintenant les demandes de différents clients seront dans la même connexion entre le backend et le proxy, il est nécessaire de maintenir une correspondance claire entre les paires requête-réponse. La plupart des procurations ne prévoient pas(pipelines) envoie des requêtes au backend et fonctionne avec lui en mode de réponse aux requêtes. Le mode demande-réponse est plus simple et soumis à pratiquement une menace: le blocage de la connexion. Si vous établissez la connexion sur une seule paire demande-réponse, vous pouvez provoquer un retard, voire un refus, pour traiter les demandes suivantes (par exemple, si vous réussissez à déborder les files d'attente de demandes de procurations).

Des proxies plus productifs acheminent les requêtes vers le backend - cela vous permet d'envoyer immédiatement un paquet de requêtes au serveur et d'attendre leur exécution. Les performances sont supérieures, mais les menaces sont plus nombreuses. Premièrement, le problème du blocage en tête de ligne ne disparaît nulle part - même si le backend peut ratisser le pipeline de requêtes et les exécuter en parallèle, elles ne peuvent pas être envoyées si la première d'entre elles se bloque. Deuxièmement, si vous cassez le cadrage de la réponse, vous pouvez confondre le proxy et rompre la correspondance des paires demande-réponse, puis certains clients peuvent obtenir les réponses d'autres personnes, ou au moins parvenir à une fermeture de connexion instantanée avec le backend.

La redéfinition la plus simple et la plus amusante d'une méthode consiste à remplacer GET par le verbe HEAD. Si la réponse à la première a un corps, la seconde non. De plus, tous les autres en-têtes sont identiques, y compris ceux qui fournissent le cadrage de la demande. Lorsque le proxy redirige une telle HEAD remplacée vers le serveur, il attend du serveur non seulement les en-têtes de réponse, mais aussi le corps de réponse, que le backend ne va pas envoyer. Si le proxy et le serveur interagissent dans le mode de demande-réponse, la connexion se "bloque" jusqu'à ce qu'elle soit interrompue par le délai d'expiration.

Si le serveur envoie les réponses suivantes (mode pipeline), elles peuvent être analysées non pas comme des réponses indépendantes, mais dans le cadre de la réponse incomplète précédente à l'EEG. Le proxy les placera (ou une partie d'entre eux) dans le corps de la réponse "GET" et l'enverra à l'attaquant pour les lire. Vous pouvez créer un tel pseudo-GET pour recevoir un fichier volumineux et vider du trafic entre le proxy et le backend. Le succès dépend de la façon dont le backend place le Content-Length et le Transfer-Encoding: des en-têtes fragmentés pour encadrer les messages. Le premier vous permettra presque toujours d'obtenir un vidage, le second générera souvent des erreurs d'analyse et provoquera une déconnexion du backend. Si vous n'êtes pas du tout chanceux, le pseudo-GET peut couvrir plusieurs réponses dans son intégralité et se terminer juste avant la réponse suivante.Le proxy ne pourra pas du tout reconnaître ce problème et pour d'autres réponses à cet égard, la correspondance demande-réponse sera violée.

Même si tout ce qui a été réalisé en remplaçant la méthode a été de fermer la connexion entre le proxy et le backend, cela peut suffire pour une attaque. Vous pouvez lancer des demandes de service avec de telles demandes - les connexions avec les backends seront constamment interrompues. Il n'y en a pas tellement, et la redécouverte prend du temps, par conséquent, vous pouvez réduire considérablement les performances de communication du serveur proxy et ainsi réduire le débit du service.

Relecture automatique du spam

J'ai dit ci-dessus que les demandes de la forme GET + X-HTTP-Method-Override: PATCH de clients respectables sont mauvaises. Et c'est mauvais parce que les méthodes ont deux propriétés: la sécurité et l' idempotence . La sécurité signifie que la méthode ne modifie pas l'état du serveur (lecture seule) et ne nous intéresse pas dans le cadre de cet article. L'idempotence de la méthode garantit que la demande répétée a le même effet qu'une demande unique. Vous pouvez faire une analogie: (a = 5)- requête idempotente, et (a += 2) - non idempotente.

Cette propriété est ce qui nous intéresse. Si la connexion entre le client et le serveur se brise soudainement, le client, sachant que la méthode est idempotente, peut renvoyer automatiquement la demande. Les mandataires se comportent de la même manière. Les requêtes non idempotentes ne sont pas répétées automatiquement car on ne sait pas comment elles affectent le serveur et ce que le client recevra à la fin. Je pense que tout le monde connaît les fenêtres contextuelles du navigateur: "Voulez-vous vraiment répéter la demande?"

Si vous masquez une méthode non idempotente comme idempotente, en cas d'erreurs, elle ne sera pas supprimée, mais sera à nouveau redirigée vers le serveur. Même si le client considérera la méthode de demande réelle avant de soumettre à nouveau la demande, cela n'aidera pas beaucoup, car le serveur proxy ne connaît pas la substitution de méthode et répétera ces demandes.

Si un attaquant est en mesure de forcer les déconnexions entre le backend et les clients, il pourra amener le serveur à exécuter à plusieurs reprises des requêtes non idempotentes et à réduire la fiabilité et la prévisibilité de l'application. Dans la section précédente, nous venons de trouver un moyen de provoquer des ruptures de connexion avec la même substitution de méthode. Bien qu'il ne faut pas oublier qu'Internet est un réseau peu fiable, par définition, et que l'application elle-même est en danger.

Pour vous protéger contre cette attaque, vous ne devez utiliser que des méthodes qui n'ajoutent pas de nouvelles propriétés à la demande en tant que transport. POST est un bon candidat, car par défaut il n'est ni sûr ni idempotent.

Cet ancien HTTP / 1.1, comme avec HTTP / 2?

HTTP / 2 a changé la façon dont les requêtes sont transportées entre les nœuds, mais il n'a pas changé leur signification lexicale. Par conséquent, dans les attaques liées à la valeur de la requête, HTTP / 2 se comporte de la même manière. Mais les attaques de «transport» ne sont pas reproduites, car elles sont déjà prises en compte dans la norme.

Les attaques sur le cache sont reproduites de manière similaire à HTTP / 1, et la protection est similaire.

Les attaques Message Queuing ne s'appliquent pas à HTTP / 2. Les messages HTTP qu'il contient sont divisés en trames distinctes, avec des en-têtes de trame distincts qui déterminent explicitement la longueur et la fin du message. Comme si l'attaquant ne changerait pas la méthode et ne modifierait pas les en-têtes HTTP, cela n'affecterait pas le cadre du message. Voler la réponse échouera.

Les attaques contre la répétition de messages non idempotents sont applicables même en tenant compte du fait que dans HTTP / 2 il y amécanisme de notification de la dernière demande traitée . Dans HTTP / 2, plusieurs requêtes sont multipliées dans le même TCP et créent ainsi des flux . Chaque fil a son propre numéro. Si le serveur HTTP / 2 se déconnecte, il peut indiquer le numéro de la dernière demande traitée dans GOAWAY. Les demandes avec un nombre plus élevé peuvent toujours être redirigées en toute sécurité; les demandes avec un nombre inférieur ne sont redirigées que si elles sont idempotentes. Si une demande avec une méthode substituée semble idempotente pour un serveur proxy, le proxy la transmettra au serveur.

Comment remplacer en toute sécurité une méthode

La réponse courte n'est pas possible. Il vaut mieux ne pas utiliser du tout les substitutions de méthode. Et désactivez complètement la prise en charge dans le backend, le cas échéant. Bloquer les méthodes de substitution des clients HTTP. Refuser le proxy / WAF, ce qui coupe les méthodes "supplémentaires".

Si vous devez en quelque sorte vivre avec la redéfinition de la méthode, alors pour empêcher suffisamment de modifications sur le backend. Tout d'abord, il est conseillé de remplacer la méthode uniquement via le composant de requête de l'URI.

Deuxièmement, il devrait y avoir une liste blanche de la transformation des méthodes: qui sont acceptables en tant que «transport» et qui en résultent. Il ne devrait pas y avoir de fonctions de transformation généralisées lorsqu'une méthode peut être remplacée par n'importe laquelle. La méthode de «transport» ne devrait pas avoir les propriétés de sécurité et d'idempotence si celle qui en résulte n'en a pas. Les transformations dangereuses doivent être interdites, le même remplacement GET -> HEAD.

Dois-je corriger un proxy / WAF problématique?

Si le proxy n'implémente que les méthodes GET et POST, et bloque les autres pour une raison ou une autre, certainement oui. Vous pouvez l'optimiser principalement pour GET et POST, mais bloquer d'autres méthodes est une mauvaise idée. Ce qui crée encore un gouffre de méfiance à l'égard du produit: si les choses de base sont bloquées, à quoi s'attendre de la mise en œuvre de problèmes plus complexes?

Si vous vous inquiétez de la sécurité des applications Web protégées, il peut être utile de sécuriser les applications contre les stratégies de substitution de méthode non sécurisées. Bien sûr, dans le cas général, sans connaître les détails de la mise en œuvre de l'application Web, il est impossible de protéger complètement l'application contre les remplacements incorrects, mais vous pouvez couvrir partiellement les utilisateurs qui ne connaissent tout simplement pas le problème. Il est nécessaire non seulement de vous protéger contre l'empoisonnement de votre propre cache, mais également de permettre d'activer ou de désactiver la substitution pour chaque application protégée. Pour ce faire, gardez une trace des en- têtes couramment utilisés.X-HTTP-Method, X-HTTP-Method-Override et X-Method-Override. Le suivi de la redéfinition dans le composant de requête de l'URI n'a pas beaucoup de sens: le cache n'empoisonne pas une telle demande, et la requête peut être très longue et avoir un format complètement arbitraire.

?

Développeurs de sécurité, ne limitez pas les développeurs d'applications aux politiques de sécurité. Ils trouveront toujours comment les contourner, et plus le protocole est flexible, plus il est facile de le faire. Il est très probable qu'ils ne vous frapperont pas et n'attendront pas que vous rendiez les restrictions plus raisonnables, mais les contournent simplement.

Si vous avez compris comment implémenter quelque chose dans le protocole, mais qu'il remplace ou va à l'encontre de l'un des concepts clés de la norme, des problèmes de compatibilité et de sécurité se poseront sûrement. Et ils doivent être couverts en même temps que la décision. À chaque fois. Si vous avez rencontré de tels conseils et n'avez pas vu d'avertissements de sécurité, ne dupliquez pas les conseils sur Internet. Soyez toujours critique envers la décision et déterminez ce qui pourrait mal tourner .

Au lieu d'une postface

Quels problèmes de serveur proxy avez-vous rencontrés? Que fallait-il contourner et comment?

Sécurité grâce à la restriction des utilisateurs ou comment créer une vulnérabilité