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

Question

Cross-origin resource sharing est un mécanisme qui permet à une page web pour faire XMLHttpRequests à un autre domaine (de wikipedia), et c'est assez important (de moi :).

J'ai été bricoler avec les CORS pour le couple des derniers jours et je pense avoir une assez bonne compréhension de la façon dont tout cela fonctionne.

Donc ma question n'est pas sur la façon de la SCRO / contrôle en amont des travaux, il est à propos de la raison derrière à venir avec preflights comme un nouveau type de demande. Je ne vois aucune raison pourquoi le serveur A besoin d'envoyer un contrôle en amont (PR) vers le serveur B juste pour savoir si la requête réelle (RR) sera accepté ou pas - il serait certainement possible pour B pour accepter/rejeter RR, sans préavis, PR.

Après avoir cherché un peu j'ai trouvé ce morceau de l'information à www.w3.org (7.1.5):

Pour protéger les ressources contre croix-de l'origine des demandes qui ne pouvaient pas provenir de certains agents utilisateurs avant cette spécification existait un contrôle en amont de la demande est effectuée pour s'assurer que la ressource est au courant de cette spécification.

Je trouve que c'est le plus difficile à comprendre la phrase jamais. Mon interprétation (pourrait l'appeler la "meilleure estimation") est qu'il s'agit de protéger le serveur B à l'encontre des demandes de serveur de C qui n'est pas conscient de la spécification.

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

Answer 1

J'ai passé un certain 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 le contrôle en amont des demandes ne sont pas une sécurité de chose. Plutôt, ils sont un pas-de changer les règles de la chose.

Le contrôle en amont des demandes n'ont rien à voir avec la sécurité, et ils n'ont pas d'incidence sur les applications qui sont en cours de développement, avec une prise de conscience de la SCRO. Plutôt, le mécanisme de contrôle en amont des avantages des serveurs qui ont été développés sans une prise de conscience de la SCRO, et il fonctionne comme un test de cohérence entre le client et le serveur qu'ils sont à la fois de la SCRO. Les développeurs de la SCRO senti qu'il y avait suffisamment de serveurs qui ont été en s'appuyant sur l'hypothèse qu'ils n'auraient jamais recevoir, par exemple, un inter-domaine de SUPPRIMER la demande qu'ils ont inventé le mécanisme de contrôle en amont pour permettre aux deux parties d'opt-in. Ils ont estimé que la solution de rechange, qui aurait été de simplement permettre à la croix-domaine des appels, aurait brisé trop d'applications existantes.

Il y a trois scénarios ici:

1. Vieux serveurs, n'est plus en développement et développés avant la SCRO. Ces serveurs peut faire des hypothèses qu'ils ne pourront jamais recevoir par exemple un cross-domain demande de SUPPRESSION. Ce scénario est le principal bénéficiaire du mécanisme de contrôle en amont. Oui ces services peuvent déjà être abusé par un malicieux ou non-conforme de l'agent utilisateur (et de la SCRO ne fait rien pour changer cela), mais dans un monde avec de la SCRO le contrôle en amont mécanisme fournit un supplément 'sanity check" pour que les clients et les serveurs ne se cassent pas parce que les règles sous-jacentes du web ont changé.

2. Les serveurs sont encore en cours de développement, mais qui contiennent beaucoup de vieux code et pour lesquels il n'est pas possible/souhaitable de la vérification de tous les vieux code pour s'assurer qu'il fonctionne correctement dans un cross-domain monde. Ce scénario permet aux serveurs d'progressivement optez pour la SCRO, par exemple en disant: "Maintenant, je vais me permettre que cet en-tête", "Maintenant, je vais me permettre ce verbe HTTP", "Maintenant, je vais autoriser les cookies/auth l'information à transmettre", etc. Ce scénario avantages du mécanisme de contrôle en amont.

3. Les nouveaux serveurs qui sont écrits avec une prise de conscience de la SCRO. Selon les normes, les pratiques de sécurité, le serveur doit protéger ses ressources dans le visage de toute demande entrante -- les serveurs peuvent pas confiance aux clients de ne pas faire les choses malveillantes. Ce scénario n'est pas bénéficier du mécanisme de contrôle en amont: le mécanisme de contrôle en amont apporte pas de sécurité supplémentaire à un serveur qui a bien protégé ses ressources.

Answer 2

Considérez le monde de cross-domain demandes avant de la SCRO. Vous pourriez faire un formulaire standard de POSTE, ou d'utiliser un script ou image balise d'émettre une requête GET. On ne pouvait pas faire tout autre type de demande, autres que GET et POST, et vous ne pouvez pas émettre des en-têtes personnalisés sur ces demandes.

Avec l'avènement de la SCRO, le spec auteurs ont été confrontés au défi de l'introduction d'un nouveau mécanisme de domaine sans casser l'existant à la sémantique du web. Ils ont choisi de le faire en donnant des serveurs d'une manière de se retirer dans un nouveau type de demande. Ce choix est le contrôle en amont de la demande.

Donc GET/POST demandes sans en-têtes personnalisés n'avez pas besoin d'un contrôle en amont, étant donné que ces demandes ont été d'ores et déjà possible avant de la SCRO. Mais toute demande avec des en-têtes personnalisés, ou d'ajouter/SUPPRIMER des demandes, ne besoin d'un contrôle en amont, puisque ceux-ci sont de nouveau à la SCRO spec. Si le serveur ne sait rien à propos de la SCRO, il répondra sans aucun de la SCRO-en-têtes spécifiques, et à la demande réelle ne sera pas faite.

Sans le contrôle en amont de la demande, les serveurs pourraient commencer à voir des demandes inattendues à partir 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 demande. De la SCRO de contrôle en amont permet des requêtes inter-domaine à être introduit sur le web de façon sécuritaire.

Answer 3

La SCRO vous permet de spécifier plusieurs en-têtes et les types de méthode que ce qui était possible auparavant avec la croix-origine <img src> ou <form action>.

Certains serveurs ont été (mal) protégé avec l'hypothèse qu'un navigateur ne peut pas faire, par exemple, cross-origin DELETE la demande ou de la croix-origine de la demande avec la X-Requested-With - tête, de sorte que de telles demandes sont "de confiance".

Assurez-vous que le serveur de vraiment-vraiment prend en charge la SCRO et pas seulement arrive à répondre au hasard à une demande, le contrôle en amont est exécutée.

Answer 4

En outre, pour les méthodes de requête HTTP susceptibles d'avoir des effets secondaires sur les données utilisateur (en particulier pour les méthodes HTTP autres que GET ou pour l'utilisation POST avec certains types MIME), la spécification oblige les navigateurs à "contrôler en amont" la requête.

La source