CORS est-il un moyen sécurisé de faire des demandes AJAX multi-domaines?

Il n'est pas conçu pour empêcher les personnes d'obtenir les données. Vous ne pouvez pas l'exposer sans que les gens l'obtiennent.

Il est conçu de sorte que donné:

• Alice, une personne fournissant une API destinée à être consultée via Ajax
• Bob, une personne avec un navigateur Web
• Charlie, un tiers qui dirige son propre site web

Si Bob visite le site Web de Charlie, Charlie ne peut pas envoyer JS au navigateur de Bob pour qu'il récupère des données du site d'Alice et l'envoie à Charlie.

La situation ci-dessus devient plus importante si Bob a un compte d'utilisateur sur le site Web d'Alice qui lui permet de faire des choses comme publier des commentaires ou supprimer des données – car sans protection, Charlie pourrait dire au navigateur de Bob de le faire derrière le dos de Bob.

Si vous souhaitez empêcher les personnes non autorisées de voir les données, vous devez vous protéger avec les mots de passe, les certificats de client SSL ou d'autres moyens d'authentification / autorisation basés sur l'identité.

Le but est d'éviter cela –

• Vous allez sur le site X
• L'auteur du site X a écrit un script malveillant qui est envoyé à votre navigateur
• Ce script s'exécutant sur votre navigateur se connecte sur le site Web de votre banque et fait du mal et parce qu'il fonctionne comme vous dans votre navigateur, il a l'autorisation de le faire.

Les idées sont que le site Web de votre banque a besoin d'indiquer à votre navigateur si les scripts sur le site X devraient être confiés pour accéder aux pages de votre banque.

Juste pour ajouter à la réponse de @jcoder, l'intégralité de l'en-tête d' Origin n'est pas de protéger les ressources demandées sur un serveur, cette tâche incombe au serveur lui-même, exactement parce qu'un attaquant est en mesure de falsifier cet en-tête avec Les outils appropriés.

Le point de l'en-tête Origin est de protéger l'utilisateur. Le scénario est le suivant:

• Un attaquant Marie crée un site Web malveillant M

• Un utilisateur Alice est trompé de se connecter à M, qui contient un script qui essaie d'effectuer certaines actions via CORS sur un serveur B qui supporte actuellement CORS

• B n'aura probablement pas M dans son en Access-Control-Allow-Origin tête Access-Control-Allow-Origin , parce que pourquoi?

• Le point central est que M n'a aucun moyen de masquer ou d'écraser l'en-tête d' Origin , car les requêtes sont lancées par le navigateur d'ALICE. Ainsi, son navigateur définira l'origine (correcte) à M, qui ne se trouve pas dans Access-Control-Allow-Origin of B, donc la demande échouera.

Maintenant, Alice pourrait modifier l'en-tête d' Origin elle-même, mais pourquoi serait-elle, car cela signifierait qu'elle se nuirait?

TL; DR: L'en-tête d' Origin protège l'utilisateur innocent. Il ne sécurise pas les ressources. Il est spoofable par un attaquant sur sa propre machine, mais il ne peut pas être falsifié sur une machine qui n'est pas sous son contrôle.

Les serveurs devraient encore protéger leurs ressources, car un en-tête d' Origin correspondant ne signifie pas un accès autorisé. Toutefois, un en-tête Origin qui ne correspond pas, signifie un accès non autorisé.

Le but de la même politique d'origine n'est pas d'empêcher les personnes d'accéder au contenu du site Web en général; Si quelqu'un veut le faire, ils n'ont même pas besoin d'un navigateur. Le but est d'empêcher les scripts clients d' accéder au contenu sur un autre domaine sans les droits d'accès nécessaires. Voir l'entrée Wikipedia pour la même politique d'origine .

Après avoir lu sur CORS, je ne comprends pas comment cela améliore la sécurité.

CORS n'améliore pas la sécurité. CORS fournit un mécanisme pour que les serveurs indiquent aux navigateurs comment les accéder à des domaines étrangers et tente de le faire d'une manière compatible avec le modèle de sécurité du navigateur qui existait avant CORS (à savoir la même politique d'origine ).

Mais la même politique d'origine et CORS ont une portée limitée. Plus précisément, la spécification CORS elle-même n'a aucun mécanisme pour rejeter les requêtes. Il peut utiliser des en-têtes pour indiquer au navigateur de ne pas laisser une page d'un domaine étranger lire une réponse. Et, dans le cas des demandes de pré-vol, il peut demander au navigateur de ne pas lui envoyer certaines demandes d'un domaine étranger. Mais CORS ne spécifie aucun moyen pour le serveur de rejeter (c'est-à-dire ne pas exécuter) une requête réelle.

Prenons un exemple. Un utilisateur est connecté au site A via un cookie. L'utilisateur charge le site malveillant M , qui essaie de soumettre un formulaire qui fait un POST à A Que se passera-t-il? Eh bien, avec ou sans CORS, et avec ou sans M étant un domaine autorisé, le navigateur enverra la demande à A avec le cookie d'autorisation de l'utilisateur et le serveur exécutera le POST malveillant comme si l'utilisateur l'avait lancé.

Cette attaque s'appelle Cross-Site Request Forgery , et CORS elle-même ne fait rien pour l'atténuer. C'est pourquoi les protections CSRF sont si importantes si vous autorisez les requêtes à modifier les données au nom des utilisateurs.

Maintenant, l'utilisation de l'en-tête Origin peut être une partie importante de votre protection CSRF. En effet, le fait de vérifier cela fait partie de la recommandation actuelle pour la défense multidimensionnelle de la CSRF . Mais cette utilisation de l'en-tête Origin est en dehors de la spécification CORS.

En somme, CORS est une spécification utile pour étendre le modèle de sécurité de la Politique de Même Identité existant à d'autres domaines acceptés. Il n'ajoute pas de sécurité et les sites ont besoin des mêmes mécanismes de défense qu'ils ont fait avant CORS.

Je suis en retard pour répondre, mais je ne pense pas que n'importe quel article ici fournisse vraiment la réponse recherchée. Le plus grand à emporter devrait être que le navigateur soit l'agent qui écrit la valeur d'en-tête d' origin . Un script mal écrit ne peut pas écrire la valeur d'en-tête d' origin . Lorsque le serveur répond avec un en Access-Control-Allow-Origin tête Access-Control-Allow-Origin , le navigateur tente de s'assurer que cet en-tête contient la valeur d' origin envoyée plus tôt. Sinon, cela déclenche une erreur et ne renvoie pas la valeur au script demandeur. Les autres réponses à cette question présentent un bon scénario lorsque vous souhaitez refuser une réponse au script malveillant.

@daniel f fournit également une bonne réponse à la question