CORS est-il un moyen sûr de faire des requêtes inter-domaines AJAX requêtes?
Après avoir lu sur CORS (Cross-Origin Resource Sharing), je ne comprends pas comment cela améliore la sécurité. Cross-Domain AJAX est autorisée si l'en-tête Origin correct est envoyé. Par exemple, si j'envoie
Origine: http://example.com
Le serveur vérifie si ce domaine est dans la liste blanche et, s'il l'est, en-tête:
Access-Control-Allow-Origin: [URL reçue ici]
est renvoyée, accompagnée de la réponse (C'est le cas simple, il y a aussi des demandes de contrôle en amont, mais la question est la même).
Est-ce vraiment sûr? Si quelqu'un veut recevoir les informations, truquer un en-tête Origin semble être une tâche vraiment triviale. La norme indique également que la stratégie est appliquée dans le navigateur, bloquant la réponse si Access-Control-Allow-Origin n'est pas correct. Évidemment, si quelqu'un essaie d'obtenir ces informations, il n'utilisera pas de navigateur standard pour les bloquer.
Il n'est pas conçu pour empêcher les gens d'obtenir les données. Vous ne pouvez pas l'exposer sans que les gens l'obtiennent.
Il est conçu de telle sorte que compte tenu:
- Alice, une personne fournissant une API conçue pour être accessible via Ajax
- Bob, une personne avec un navigateur Web
- Charlie, un tiers qui gère 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 les données du site Web d'Alice et les 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 dans 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 des mots de passe, des certificats client SSL ou d'autres moyens d'authentification/autorisation basés sur l'identité.
Le but est d'empêcher cela -
- Vous allez sur le site X
- L'auteur du site Web X a écrit un mauvais script qui est envoyé à votre navigateur
- ce script exécuté sur votre navigateur se connecte à votre site Web de banque et fait du mal et parce qu'il s'exécute comme vous dans votre navigateur, il est autorisé à le faire.
L'idée est que le site Web de votre banque a besoin d'un moyen d'indiquer à votre navigateur si les scripts du site Web X doivent être approuvés pour accéder aux pages de votre banque.
Juste pour ajouter à la réponse de @jcoder, tout l'intérêt de l'en-tête Origin, n'est pas de protéger les ressources demandées sur un serveur, cette tâche revient au serveur lui-même par d'autres moyens, précisément parce qu'un attaquant est en effet capable d'usurper cet en-tête avec les outils appropriés.
Le but de l'en-tête Origin est de protéger l'utilisateur. Le scénario est le suivant:
un attaquant crée un site web malveillant M
un utilisateur Alice est trompé pour se connecter à M, qui contient un script qui essaie d'effectuer certaines actions via CORS sur un serveur B qui prend en charge CORS
B n'aura probablement pas M dans son
Access-Control-Allow-Originen-tête, pourquoi le ferait-il?Le point crucial est que M n'a aucun moyen d'usurper ou d'écraser l'en-tête
Origin, car les requêtes sont lancées par le navigateur d'Alice. Son navigateur définira donc le (correct)Originsur M, qui n'est pas dans leAccess-Control-Allow-Originde B, par conséquent la demande échouera.
Maintenant, Alice pourrait elle-même modifier l'en-tête Origin, mais pourquoi le ferait-elle, car cela signifierait qu'elle se fait du mal?
TL; DR: l'en-tête Origin protège l'utilisateur innocent. Il ne sécurise pas les ressources. Il peut être usurpé par un attaquant sur sa propre machine, mais il ne peut pas être usurpé sur une machine qui n'est pas sous son contrôle.
Les serveurs doivent toujours protéger leurs ressources, car un en-tête Origin correspondant ne signifie pas un accès autorisé. Cependant, 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 gens d'accéder au contenu du site Web en général; si quelqu'un veut le faire, il n'a même pas besoin d'un navigateur. Le but est d'arrêter les scripts clients d'accéder au contenu d'un autre domaine sans les droits d'accès nécessaires. Voir l'entrée Wikipedia pour 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 permettant aux serveurs d'indiquer aux navigateurs comment les domaines étrangers devraient y accéder, et il essaie de le faire d'une manière cohérente avec le modèle de sécurité du navigateur qui existait avant CORS (à savoir 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 ne dispose d'aucun mécanisme pour rejeter les demandes. 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 de demandes de contrôle en amont, il peut demander au navigateur de ne pas lui envoyer certaines demandes depuis un domaine étranger. Mais CORS ne spécifie aucun moyen pour le serveur de rejeter (c'est-à-dire de ne pas exécuter) une demande 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 va-t-il se passer? 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 malware POST comme si l'utilisateur l'avait initié.
Cette attaque est appelée Cross-Site Request Forgery , et CORS lui-même ne fait rien pour l'atténuer. C'est pourquoi les protections CSRF sont si importantes si vous autorisez les demandes de modification des données au nom des utilisateurs.
Maintenant, l'utilisation de l'en-tête Origin peut être un élément important de votre protection CSRF. En effet, sa vérification fait partie de la recommandation actuelle pour la défense CSRF à plusieurs volets . Mais cette utilisation de l'en-tête Origin ne relève pas de la spécification CORS.
En résumé, CORS est une spécification utile pour étendre le modèle de sécurité existant de la même politique d'origine à d'autres domaines acceptés. Cela n'ajoute pas de sécurité et les sites ont besoin des mêmes types de mécanismes de défense qu'avant CORS.
Je suis en retard pour répondre, mais je ne pense pas qu'un post ici fournisse vraiment la réponse recherchée. Le plus grand point à retenir devrait être que le navigateur est l'agent qui écrit la valeur d'en-tête Origin. Un mauvais script ne peut pas écrire la valeur d'en-tête Origin. Lorsque le serveur répond avec un Access-Control-Allow-Origin header, le navigateur essaie de s'assurer que cet en-tête contient la valeur Origin envoyée précédemment. Sinon, il 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 dans lequel vous souhaitez refuser une réponse au script diabolique.
@daniel f fournit également une bonne réponse à la question