CORS - Quelle est la motivation derrière l'introduction de demandes de contrôle en amont?

Le partage de ressources d'origine croisée est un mécanisme qui permet à une page Web de faire XMLHttpRequests vers un autre domaine (à partir de wikipedia ).

Je bidouille avec CORS depuis quelques jours et je pense que je comprends assez bien comment tout fonctionne.

Donc, ma question n'est pas sur le fonctionnement de CORS / preflight, mais sur la raison derrière la création de preflights comme nouveau type de demande . Je ne vois aucune raison pour laquelle le serveur A doit envoyer un contrôle en amont (PR) au serveur B juste pour savoir si la vraie demande (RR) sera acceptée ou non - il serait certainement possible pour B d'accepter / rejeter RR sans tout PR précédent.

Après avoir cherché un peu, j'ai trouvé cette information sur www.w3.org (7.1.5):

Pour protéger les ressources contre les demandes d'origine croisée qui ne pouvaient pas provenir de certains agents utilisateurs avant que cette spécification n'existe, une demande de contrôle en amont est effectuée pour s'assurer que la ressource est au courant de cette spécification.

Je trouve que c'est la phrase la plus difficile à comprendre de tous les temps. Mon interprétation (devrait mieux l'appeler «meilleure estimation») est qu'il s'agit de protéger le serveur B contre les demandes du serveur C qui n'est pas au courant de la spécification.

Quelqu'un peut-il expliquer un scénario / montrer un problème que PR + RR résout mieux que RR seul?

J'ai passé un peu de temps à être confus quant à l'objet de la demande de contrôle en amont, mais je pense que je l'ai maintenant.

L'idée clé est que les demandes de contrôle en amont ne sont pas une question de sécurité . C'est plutôt une chose qui ne change pas les règles .

Les demandes de contrôle en amont n'ont rien à voir avec la sécurité, et elles n'ont aucune incidence sur les applications en cours de développement, avec une connaissance de CORS. Au contraire, le mécanisme de contrôle en amont profite aux serveurs qui ont été développés sans connaissance de CORS, et il fonctionne comme un contrôle d'intégrité entre le client et le serveur qu'ils sont tous deux conscients de CORS. Les développeurs de CORS ont estimé qu'il y avait suffisamment de serveurs qui comptaient sur l'hypothèse qu'ils ne recevraient jamais, par exemple une demande DELETE interdomaine qu'ils avaient inventé le mécanisme de contrôle en amont pour permettre aux deux parties de s'inscrire. Ils ont estimé que l'alternative, qui aurait simplement consisté à activer les appels interdomaines, aurait brisé trop d'applications existantes.

Il existe trois scénarios ici:

1. Anciens serveurs, plus en cours de développement, et développés avant CORS. Ces serveurs peuvent émettre l'hypothèse qu'ils ne recevront jamais, par exemple, une demande DELETE interdomaine. Ce scénario est le principal bénéficiaire du mécanisme de contrôle en amont. Oui, ces services pourraient déjà être utilisés abusivement par un agent utilisateur malveillant ou non conforme (et CORS ne fait rien pour changer cela), mais dans un monde avec CORS, le mécanisme de contrôle en amont fournit un `` contrôle de cohérence '' supplémentaire afin que les clients et les serveurs ne le fassent pas. casser parce que les règles sous-jacentes du Web ont changé.

2. Serveurs qui sont encore en cours de développement, mais qui contiennent beaucoup d'ancien code et pour lesquels il n'est pas possible / souhaitable d'auditer tout l'ancien code pour s'assurer qu'il fonctionne correctement dans un monde inter-domaines. Ce scénario permet aux serveurs de s'abonner progressivement à CORS, par exemple en disant "Maintenant, je vais autoriser cet en-tête particulier", "Maintenant, je vais autoriser ce verbe HTTP particulier", "Maintenant, je vais autoriser les cookies / informations d'authentification à être envoyé ", etc. Ce scénario bénéficie du mécanisme de contrôle en amont.

3. Nouveaux serveurs écrits avec une connaissance de CORS. Selon les pratiques de sécurité standard, le serveur doit protéger ses ressources face à toute demande entrante - les serveurs ne peuvent pas faire confiance aux clients pour ne pas faire de choses malveillantes. Ce scénario ne bénéficie pas du mécanisme de contrôle en amont : le mécanisme de contrôle en amont n'apporte aucune sécurité supplémentaire à un serveur qui a correctement protégé ses ressources.

Quelle était la motivation derrière l'introduction des demandes de contrôle en amont?

Des demandes de contrôle en amont ont été introduites afin qu'un navigateur puisse être sûr qu'il traite avec un serveur compatible CORS avant d'envoyer certaines demandes. Ces demandes ont été définies comme étant à la fois potentiellement dangereuses (à changement d'état) et nouvelles (non possibles avant CORS en raison de la même politique d'origine ). L'utilisation de demandes de contrôle en amont signifie que les serveurs doivent accepter (en répondant correctement au contrôle en amont) les nouveaux types de demandes potentiellement dangereux que CORS rend possibles.

C'est le sens de cette partie de la spécification : "Pour protéger les ressources contre les demandes d'origine croisée qui ne pouvaient pas provenir de certains agents utilisateurs avant que cette spécification n'existe, une demande de contrôle en amont est effectuée pour s'assurer que la ressource est au courant de cette spécification."

Peux-tu me donner un exemple?

Imaginons qu'un utilisateur de navigateur soit connecté à son site bancaire à l'adresse A.com. Lorsqu'ils accèdent au malware B.com, cette page contient du Javascript qui essaie d'envoyer une DELETEdemande à A.com/account. Étant donné que l'utilisateur est connecté A.com, cette demande, si elle est envoyée, comprendrait des cookies qui identifient l'utilisateur.

Avant CORS, la même politique d'origine du navigateur l'aurait empêché d'envoyer cette demande. Mais comme le but de CORS est de rendre possible ce type de communication entre origines, ce n'est plus approprié.

Le navigateur peut simplement envoyer le DELETEfichier et laisser le serveur décider comment le gérer. Mais que faire si A.comvous n'êtes pas au courant du protocole CORS? Il pourrait aller de l'avant et exécuter le dangereux DELETE. Il aurait pu supposer que - en raison de la même politique d'origine du navigateur - il ne pourrait jamais recevoir une telle demande, et donc il n'aurait peut-être jamais été renforcé contre une telle attaque.

Pour protéger de tels serveurs non compatibles CORS, le protocole nécessite alors que le navigateur envoie d'abord une demande de contrôle en amont . Ce nouveau type de demande est quelque chose auquel seuls les serveurs compatibles CORS peuvent répondre correctement, permettant au navigateur de savoir s'il est sûr ou non d'envoyer les données réelles DELETE.

Pourquoi tout ce tapage sur le navigateur, l'attaquant ne peut-il pas simplement envoyer une DELETEdemande depuis son propre ordinateur?

Bien sûr, mais une telle demande n'inclura pas les cookies de l'utilisateur. L'attaque que cela est conçu pour empêcher repose sur le fait que le navigateur enverra des cookies (en particulier, des informations d'authentification pour l'utilisateur) pour l'autre domaine avec la demande.

Cela sonne comme Cross-Site Request Forgery , où une forme sur place B.compeut POSTà A.comavec les cookies de l'utilisateur et faire des dégâts.

C'est vrai. Une autre façon de dire cela est que les demandes de contrôle en amont ont été créées afin de ne pas augmenter la surface d'attaque CSRF pour les serveurs non compatibles CORS.

Mais en regardant les exigences pour les demandes "simples" qui ne nécessitent pas de contrôle en amont, je vois que cela POSTest toujours autorisé. Cela peut changer l'état et supprimer des données comme un DELETE!

C'est vrai! CORS ne protège pas votre site contre les attaques CSRF. Là encore, sans CORS, vous n'êtes également pas protégé contre les attaques CSRF. Le but des demandes de contrôle en amont est simplement de limiter votre exposition CSRF à ce qui existait déjà dans le monde pré-CORS.

Soupir. OK, j'accepte à contrecœur le besoin de demandes de contrôle en amont. Mais pourquoi devons-nous le faire pour chaque ressource (URL) sur le serveur? Le serveur gère CORS ou non.

Êtes-vous sûr de cela? Il n'est pas rare que plusieurs serveurs gèrent les demandes d'un seul domaine. Par exemple, il peut arriver que les demandes A.com/url1soient traitées par un type de serveur et que les demandes A.com/url2soient traitées par un autre type de serveur. Ce n'est généralement pas le cas que le serveur qui gère une seule ressource peut garantir la sécurité de toutes les ressources de ce domaine.

Bien. Faisons un compromis. Créons un nouvel en-tête CORS qui permet au serveur d'indiquer exactement de quelles ressources il peut parler, afin d'éviter des demandes de contrôle en amont supplémentaires à ces URL.

Bonne idée! En fait, l'en-tête a Access-Control-Policy-Pathété proposé à cette fin. En fin de compte, cependant, elle a été laissée en dehors de la spécification, apparemment parce que certains serveurs ont incorrectement implémenté la spécification URI de telle manière que les requêtes vers des chemins qui semblaient sûrs pour le navigateur ne seraient en fait pas sûres sur les serveurs cassés.

Était-ce une décision prudente qui privilégiait la sécurité aux performances, permettant aux navigateurs de mettre immédiatement en œuvre la spécification CORS sans mettre en danger les serveurs existants? Ou était-ce à courte vue de condamner Internet à une bande passante gaspillée et à une latence doublée juste pour accueillir des bogues dans un serveur particulier à un moment particulier?

Les opinions diffèrent.

Eh bien, à tout le moins, les navigateurs mettront en cache le contrôle en amont pour une seule URL?

Oui. Mais probablement pas pour très longtemps. Dans les navigateurs WebKit, la durée maximale du cache de contrôle en amont est actuellement de 10 minutes .

Soupir. Eh bien, si je sais que mes serveurs sont compatibles CORS et n'ont donc pas besoin de la protection offerte par les demandes de contrôle en amont, est-il possible de les éviter?

Votre seule véritable option est de vous assurer que vous répondez aux exigences des demandes "simples". Cela pourrait signifier laisser de côté les en-têtes personnalisés que vous auriez autrement inclus (comme X-Requested-With), mentir sur le Content-Type, ou plus.

Quoi que vous fassiez, vous devez vous assurer que vous disposez de protections CSRF appropriées, car la spécification CORS ne traite pas du rejet des demandes "simples", y compris les demandes non sécurisées POST. Comme le dit la spécification : "les ressources pour lesquelles les requêtes simples ont une signification autre que la récupération doivent se protéger contre la contrefaçon de requêtes intersites".

Considérez le monde des demandes interdomaines avant CORS. Vous pouvez faire un POST de formulaire standard, ou utiliser un scriptou un imagetag pour émettre une demande GET. Vous ne pouviez pas faire d'autre type de demande que GET / POST et vous ne pouviez pas émettre d'en-tête personnalisé sur ces demandes.

Avec l'avènement de CORS, les auteurs de la spécification ont été confrontés au défi d'introduire un nouveau mécanisme interdomaines sans rompre la sémantique existante du Web. Ils ont choisi de le faire en donnant aux serveurs un moyen d'activer tout nouveau type de demande. Cet opt-in est la demande de contrôle en amont.

Les requêtes GET / POST sans en-têtes personnalisés n'ont donc pas besoin d'un contrôle en amont, car ces requêtes étaient déjà possibles avant CORS. Mais toute demande avec les en- têtes personnalisés, ou des demandes PUT / DELETE, faire ont besoin d' un contrôle en amont, puisque ceux - ci sont nouveaux à la spécification CORS. Si le serveur ne sait rien de CORS, il répondra sans en-têtes spécifiques à CORS et la demande réelle ne sera pas effectuée.

Sans la demande de contrôle en amont, les serveurs pourraient commencer à voir des demandes inattendues de navigateurs. Cela pourrait entraîner un problème de sécurité si les serveurs n'étaient pas préparés pour ce type de demandes. Le contrôle en amont CORS permet aux requêtes interdomaines d'être introduites sur le Web en toute sécurité.

CORS vous permet de spécifier plus d'en-têtes et de types de méthodes qu'il n'était possible auparavant avec l'origine croisée <img src>ou <form action>.

Certains serveurs auraient pu être (mal) protégés avec l'hypothèse qu'un navigateur ne peut pas faire, par exemple, une DELETEdemande d' origine croisée ou une demande d' origine croisée avec en- X-Requested-Withtête, de sorte que ces demandes sont «approuvées».

Pour vous assurer que le serveur prend vraiment en charge CORS et ne répond pas simplement aux demandes aléatoires, le contrôle en amont est exécuté.

Voici une autre façon de voir les choses en utilisant du code:

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

Avant CORS, la tentative d'exploitation ci-dessus échouerait car elle violerait la politique de même origine. Une API conçue de cette façon n'avait pas besoin de protection XSRF, car elle était protégée par le modèle de sécurité natif du navigateur. Il était impossible pour un navigateur pré-CORS de générer un POST JSON d'origine croisée.

Maintenant, CORS entre en scène - si l'adhésion à CORS via le pré-vol n'était pas nécessaire, ce site aurait soudain une vulnérabilité énorme, sans aucune faute de leur part.

Pour expliquer pourquoi certaines demandes sont autorisées à sauter le pré-vol, ceci est répondu par la spécification:

Une simple demande d'origine croisée a été définie comme conforme à celles qui peuvent être générées par des agents utilisateurs actuellement déployés qui ne sont pas conformes à cette spécification.

Pour démêler cela, GET n'est pas pré-volé car c'est une "méthode simple" telle que définie par 7.1.5. (Les en-têtes doivent également être "simples" afin d'éviter le pré-vol). La justification de ceci est que la "simple" demande GET d'origine croisée pourrait déjà être effectuée par exemple <script src="">(c'est ainsi que fonctionne JSONP). Étant donné que tout élément avec un srcattribut peut déclencher un GET d'origine croisée, sans pré-vol, il n'y aurait aucun avantage en termes de sécurité à exiger un pré-combat sur des XHR "simples".

Je pense que les autres réponses ne se concentrent pas sur la raison pour laquelle le pré-combat améliore la sécurité.

Scénarios:

1) Avec pré-vol . Un attaquant falsifie une demande du site dummy-forums.com tandis que l'utilisateur est authentifié sur safe-bank.com
Si le serveur ne vérifie pas l'origine et a en quelque sorte un défaut, le navigateur émettra une demande de pré-vol, OPTION méthode. Le serveur ne sait rien de ce CORS que le navigateur attend comme réponse, de sorte que le navigateur ne procédera pas (aucun mal que ce soit)

2) Sans pré-vol . Un attaquant falsifie la demande dans le même scénario que ci-dessus, le navigateur émet immédiatement la demande POST ou PUT, le serveur l'accepte et peut la traiter, cela peut potentiellement causer des dommages.

Si l'attaquant envoie une demande directement, d'origine croisée, à partir d'un hôte aléatoire, il est fort probable que l'on pense à une demande sans authentification. C'est une demande falsifiée, mais pas une demande xsrf. donc le serveur aura vérifier les informations d'identification et échouera. CORS ne tente pas d'empêcher un attaquant disposant des informations d'identification pour émettre des demandes, bien qu'une liste blanche puisse aider à réduire ce vecteur d'attaque.

Le mécanisme de pré-vol ajoute la sécurité et la cohérence entre les clients et les serveurs. Je ne sais pas si cela vaut la poignée de main supplémentaire pour chaque demande, car la mise en cache est robuste, mais c'est ainsi que cela fonctionne.

De plus, pour les méthodes de requête HTTP qui peuvent provoquer des effets secondaires sur les données utilisateur (en particulier, pour les méthodes HTTP autres que GET, ou pour une utilisation POST avec certains types MIME), la spécification exige que les navigateurs "contrôlent" la demande

La source

Les demandes de pré-vol sont nécessaires pour les demandes qui peuvent changer d'état sur le serveur. Il existe 2 types de demandes -

1) Appels qui ne peuvent pas changer d'état sur le serveur (comme GET) - L'utilisateur peut obtenir une réponse pour la demande (si le serveur ne vérifie pas l'origine) mais si le domaine demandeur n'est pas ajouté à l'en-tête de réponse Access-Control- Allow-Origin, le navigateur n'affiche pas les données à l'utilisateur, c'est-à-dire que la demande est envoyée à partir du navigateur mais l'utilisateur n'est pas en mesure d'afficher / d'utiliser la réponse.

2) Appels pouvant changer d'état sur le serveur (comme POST, DELETE) - Depuis en 1), nous voyons que le navigateur ne bloque pas la demande mais la réponse, les appels changeant d'état ne devraient pas être autorisés sans contrôles préalables . De tels appels peuvent apporter des modifications à un serveur de confiance qui ne vérifie pas l'origine des appels (appelé Cross Site Request Forgery), même si la réponse au navigateur peut être un échec. Pour cette raison, nous avons le concept de demandes pré-vol qui effectuent un appel OPTIONS avant que tout appel à changement d'état puisse être envoyé au serveur.

Les demandes de contrôle en amont ne concernent-elles pas les performances ? Avec les demandes de contrôle en amont, un client peut rapidement savoir si l'opération est autorisée avant d'envoyer une grande quantité de données, par exemple en JSON avec la méthode PUT. Ou avant de voyager des données sensibles dans les en-têtes d'authentification sur le fil.

Le fait de PUT, DELETE et d'autres méthodes, en plus des en-têtes personnalisés, ne sont pas autorisés par défaut (ils ont besoin d'une autorisation explicite avec "Access-Control-Request-Methods" et "Access-Control-Request-Headers"), qui sonne tout comme une double vérification, car ces opérations pourraient avoir plus d'implications sur les données utilisateur, à la place des requêtes GET. Cela ressemble donc à:

"J'ai vu que vous autorisez les demandes intersites à partir de http: //foo.example , MAIS êtes-vous SÛR que vous autoriserez les demandes DELETE? Avez-vous pris en compte les impacts que ces demandes pourraient provoquer dans les données utilisateur?"

Je n'ai pas compris la corrélation citée entre les demandes de contrôle en amont et les avantages des anciens serveurs. Un service Web qui a été implémenté avant CORS, ou sans connaissance de CORS, ne recevra jamais de demande intersite, car tout d'abord, leur réponse n'aura pas l'en-tête "Access-Control-Allow-Origin".

Dans un navigateur prenant en charge CORS, les demandes de lecture (comme GET) sont déjà protégées par la même politique d'origine: un site Web malveillant essayant de faire une demande interdomaine authentifiée (par exemple vers le site Web de banque en ligne de la victime ou l'interface de configuration du routeur) ne sera pas pouvoir lire les données renvoyées car la banque ou le routeur ne définit pas l'en- Access-Control-Allow-Origintête.

Cependant, avec l' écriture de demandes (comme POST), le dommage est causé lorsque la demande arrive sur le serveur Web. * Un serveur Web pourrait vérifier l'en- Origintête pour déterminer si la demande est légitime, mais cette vérification n'est souvent pas implémentée car le serveur Web n'a pas besoin pour CORS ou le serveur Web est plus ancien que CORS et suppose donc que les POST interdomaines sont complètement interdits par la même politique d'origine.

C'est pourquoi les serveurs Web ont la possibilité de choisir de recevoir des demandes d'écriture interdomaines .

_{* Essentiellement la version AJAX de CSRF.}