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

366

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?

jan groth
la source

Réponses:

323

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.

Michael Iles
la source
12
Si tel est le cas, pourquoi est-il envoyé à chaque demande? Une demande par serveur doit être suffisante pour déterminer si le serveur connaît CORS.
Douglas Ferguson
3
La spécification inclut un cache de résultat de contrôle en amont dans le navigateur. Ainsi, bien que la sécurité soit délicate et inefficace, il semble possible de configurer de nouveaux serveurs pour que le contrôle en amont soit mis en cache indéfiniment.
Michael Cole
7
Je conviens que les demandes de contrôle en amont ne sont pas intrinsèquement liées à la sécurité, mais il semble que l'utilisation des demandes de contrôle en amont par CORS soit définitivement pour des raisons de sécurité. C'est plus qu'un simple contrôle d'intégrité pour éviter un scénario d'erreur relativement inoffensif. Si l'agent utilisateur envoyait aveuglément la demande au serveur, en supposant à tort que le serveur implémentait CORS, il accepterait très probablement des contrefaçons de demande intersite. Même si la réponse ne serait pas lisible par javascript, le serveur a peut-être déjà pris des mesures indésirables comme supprimer un compte ou effectuer un virement bancaire.
Alexander Taylor
6
Le problème est que le cache de résultat de contrôle en amont est fondamentalement inutile car 1. il ne s'applique qu'à la requête exacte, pas à l'ensemble du domaine, donc toutes les requêtes vont de toute façon effectuer un contrôle en amont la première fois; et 2. tel qu'implémenté, il est limité à 10 minutes dans la plupart des navigateurs, donc même pas indéfiniment.
davidgoli
2
@VikasBansal Le serveur existant doit "s'inscrire" et accepter de partager ses ressources entre les origines en configurant la façon dont il répond à la demande d'option de contrôle en amont. S'ils ne répondent pas explicitement à la demande de contrôle en amont, le navigateur n'émettra pas la demande réelle. Après tout, tous les serveurs ne voudront pas accepter les demandes d'origine croisée.
Kevin Lee
217

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".

Kevin Christopher Henry
la source
21
C'est le meilleur morceau d'introduction que j'ai lu sur CORS. Je vous remercie!
kiv
5
Génialement expliqué.
Pratz
4
C'est la meilleure réponse que j'ai vue sur le sujet. Très bien expliqué!
alaboudi
3
CORS est un matériau délicat, et ce post met en lumière certains points cachés
Stanislav Verjikovskiy
1
@Yos: Le navigateur inclurait ces cookies car c'est ainsi que les navigateurs devraient fonctionner (comme codifié dans des normes comme RFC 6265 ). Qu'un navigateur utilise ou non des processus distincts pour les onglets est un détail d'implémentation, il ne l'empêchera pas d'envoyer des cookies.
Kevin Christopher Henry
51

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é.

monsur
la source
Comment faire une demande POST via une balise script / img?
freakish
2
Tu ne peux pas. Je voulais dire que vous pouvez soit faire une forme POST, OU faire un GET en utilisant un script / img. J'ai édité le post pour, espérons-le, clarifier cela.
monsur
Je vois. Ça a du sens.
freakish
5
Merci pour la réponse, qui a certainement complété ma photo! Malheureusement, je ne vois toujours pas le point central derrière les contrôles en amont. Concernant votre réponse: Que serait une « demande inattendue »? Comment serait-il «plus» inattendu / moins sûr dans un monde sans contrôle en amont que dans un monde en contrôle en amont (avec par exemple un contrôle en amont perdu ou un navigateur malveillant qui «oublie» simplement le contrôle en amont)?
jan groth
7
Il existe probablement des API qui s'appuient sur la politique de même origine du navigateur pour protéger leurs ressources. Ils devraient avoir une sécurité supplémentaire, mais ils s'appuient plutôt sur la même politique d'origine. Sans le contrôle en amont, un utilisateur d'un autre domaine pourrait désormais envoyer une demande à l'API. L'API supposerait que la demande est valide (car elle ne connaît rien de CORS) et exécuterait la demande. Le navigateur peut empêcher la réponse d'atteindre l'utilisateur, mais à ce stade, les dommages peuvent déjà être causés. Si la demande était un PUT / DELETE, la ressource peut avoir été mise à jour ou supprimée.
monsur
37

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é.

Kornel
la source
12
Cela aurait dû être la réponse acceptée. C'est le plus clair et le plus pertinent. En substance, le seul point de demande de contrôle en amont est d'intégrer les normes Web pré-CORS aux normes Web post-CORS.
chopper draw lion4
2
J'aime cette réponse, mais je pense que cela ne peut pas être la raison complète ... "l'hypothèse de confiance" ne doit s'appliquer qu'à des choses que seul le navigateur peut faire (en particulier, l'envoi des informations utilisateur du navigateur limité à leur domaine - c'est-à-dire les cookies). Si cela ne faisait pas partie de l'hypothèse, alors tout ce qu'une demande de navigateur multi-origine peut faire pourrait déjà être fait par un agent tiers non navigateur, non?
Fabio Beltramini
2
@FabioBeltramini Oui, les non-navigateurs peuvent envoyer tout ce qu'ils veulent. Cependant, les attaques via les navigateurs sont spéciales parce que vous pouvez faire faire des choses aux navigateurs des autres, à partir de leur propre IP, avec leurs propres cookies, etc.
Kornel
Je commence à voir le vrai problème. Merci pour les commentaires et la réponse @FabioBeltramini et la réponse de Kronel. Si la vérification pré-vol n'est pas là, un attaquant pourrait mettre du code JavaScript sur son site mais exécuté à partir des ordinateurs de beaucoup d'autres personnes. Tous les autres clients sont assez difficiles à «embaucher» pour le faire, y compris les applications mobiles.
Xiao Peng - ZenUML.com
16

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".

Dylan Tack
la source
1
@MilesRout: Telnet ne fait pas partie du modèle de menace que les contrôles en amont visent à atténuer. Le contrôle en amont est pertinent pour les navigateurs qui 1) s'appuient sur des «autorités ambiantes» stockées (par exemple, les cookies) et 2) peuvent être amenés à abuser de cette autorité par un tiers (par exemple, la falsification de demandes intersites). Le modèle généralisé est connu sous le nom de problème de député confus .
Dylan Tack
C'est le problème avec l'autorité ambiante, vous pouvez toujours en abuser.
Miles Rout
13

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.

Hirako
la source
Convenez du problème d'attaque CSRF qui est toujours possible contre les "nouveaux serveurs" mentionnés dans la réponse de @ michael-iles.
anguille ghEEz
Il s'agit d'une description utile qu'il serait probablement utile d'enregistrer ailleurs. Peut-être envisager de l'ajouter à l'une des pages MDN?
Sideshowbarker
Mais pourquoi certaines demandes comme POST avec Content-Type text / plain ne font pas de demande avant le vol? Dans ma tête, chaque demande d'écriture (POST, PUT, DELETE) devrait avoir cette demande de pré-vol si la sécurité est un problème.
Israel Fonseca
POST avec text / plain est considéré comme une simple demande - notez que le navigateur n'affichera pas la réponse si l'origine ne correspond pas (ce qui serait le cas si le serveur n'est pas configuré pour CORS).
Hirako
Du côté de l'attaque, il y a des choses intéressantes qui peuvent être faites, en exploitant le fait que les requêtes simples sont tolérées et seront envoyées par la plupart des navigateurs. par exemple ceci .
Hirako
3

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

Oliver Weichhold
la source
2

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.

Aditi Garg
la source
1

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".

Nipo
la source
4
Vous comprenez mal Access-Control-Allow-Origin. L'absence de cet en-tête n'empêche pas le navigateur d'envoyer des demandes, il empêche simplement JS de pouvoir lire les données dans la réponse.
Dylan Tack
Pourriez-vous expliquer ceci: «L'absence de cet en-tête n'empêche pas le navigateur d'envoyer des demandes, cela empêche simplement JS de pouvoir lire les données dans la réponse», je ne comprends pas complètement.
SiddharthBhagwan
@DylanTack Bon point. Cela me fait cependant me demander pourquoi un GET xhr n'est pas également le contrôle en amont? Bien que peu probable, les demandes GET pourraient également être nuisibles / mutantes. De plus, comme tout cela pourrait être résolu avec CSRF, cela me semble que le navigateur est en train de surprotéger des serveurs qui sont trop négligents pour mettre en œuvre des pratiques de sécurité courantes.
Peleg
La réponse acceptée l'explique bien, en tant que "chose qui ne change pas les règles" (rétrocompatibilité avec les sites Web créés avant que CORS existe). Il est toujours intéressant de voir le code, j'ai donc posté une autre réponse avec un exemple de code.
Dylan Tack
1

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.

AndreKR
la source