Est-CORS un moyen sûr de faire des demandes d'AJAX inter-domaines?

Question

Après avoir lu CORS (Cross-Partage des ressources d'origine), je ne comprends pas comment il améliore la sécurité. communication inter-domaines AJAX est autorisée si l'en-tête ORIGIN correcte est envoyé. À titre d'exemple, si j'envoie

ORIGINE: http://example.com

Le serveur vérifie si ce domaine est dans la liste blanche et, si elle est, en-tête:

Accès-Control-Allow-origine: [url reçue ici]

est renvoyé, ainsi que la réponse (Ceci est le cas simple, il y a aussi des demandes prefighted, mais la question est la même).

Est-ce vraiment sûr? Si quelqu'un veut recevoir les informations, truquer un en-têtes ORIGIN semble une tâche vraiment trivial. Aussi la norme dit que la politique est appliquée dans le navigateur, bloquant la réponse si Access-Control-Allow-Origin est incorrect. Il est évident que si quelqu'un tente d'obtenir cette information, il ne sera pas utiliser un navigateur standard pour le bloquer.

Answer 1

Vous ne pouvez pas truquer un en-tête d'origine avec JavaScript dans un navigateur Web. CORS est conçu pour empêcher cela.

En dehors d'un navigateur Web, il n'a pas d'importance. Il n'a pas été conçu pour les gens d'empêcher d'obtenir des données qui sont à la disposition du public. Vous ne pouvez pas l'exposer au public sans les membres du public l'obtenir.

Il est conçu de telle sorte que, compte tenu:

• Alice, une personne qui fournit une API destinée à être accessible via Ajax
• Bob, une personne avec un navigateur web
• Charlie, un tiers la gestion de leur propre site web

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

La situation ci-dessus devient plus important si Bob a un compte d'utilisateur sur le site Web d'Alice qui lui permet de faire des choses comme poster des commentaires, des données de suppression, ou voir les données qui est pas à la disposition du grand public - puisque sans protection, JS Charlie pourrait indiquer au navigateur de Bob à faire dans le dos de Bob (puis envoyer les résultats à Charlie).

Si vous voulez arrêter des personnes non autorisées de voir les données, alors vous devez le protéger avec des mots de passe, certs client SSL ou d'autres moyens d'authentification / autorisation basée sur l'identité.

Answer 2

The purpose is to prevent this -

• You go to website X
• The author of website X has written an evil script which gets sent to your browser
• that script running on your browser logs onto your bank website and does evil stuff and because it's running as you in your browser it has permission to do so.

The ideas is that your bank's website needs some way to tell your browser if scripts on website X should be trusted to access pages at your bank.

Answer 3

Just to add on @jcoder 's answer, the whole point of the Origin header isn’t to protect the resources requested on a server. That task is up to the server itself via other means exactly because an attacker is indeed able to spoof this header with the appropriate tools.

The point of the Origin header is to protect the user. The scenario is the following:

• an attacker creates a malicious website M

• a user Alice is tricked to connect to M, which contains a script that tries to perform some actions through CORS on a server B that actually supports CORS

• B will probably not have M in its Access-Control-Allow-Origin header, cause why would it?

• The pivotal point is that M has no means to spoof or overwrite the Origin header, because the requests are initiated by Alice's browser. So her browser will set the (correct) Origin to M, which is not in the Access-Control-Allow-Origin of B, therefore the request will fail.

Alice could alter the Origin header herself, but why would she, since it would mean she is harming herself?

TL;DR: The Origin header protects the innocent user. It does not secure resources on a server. It is spoofable by an attacker on his own machine, but it cannot be spoofed on a machine not under his control.

Servers should still protect their resources, as a matching Origin header doesn't mean an authorized access. However, a Origin header that does NOT match means an unauthorized access.

Answer 4

The purpose of the same origin policy isn't to stop people from accessing website content generally; if somebody wants to do that, they don't even need a browser. The point is to stop client scripts accessing content on another domain without the necessary access rights. See the Wikipedia entry for Same Origin Policy.

Answer 5

After reading about CORS, I don't understand how it improves security.

CORS does not improve security. CORS provides a mechanism for servers to tell browsers how they should be accessed by foreign domains, and it tries to do so in a way that is consistent with the browser security model that existed before CORS (namely the Same Origin Policy).

But the Same Origin Policy and CORS have a limited scope. Specifically, the CORS specification itself has no mechanism for rejecting requests. It can use headers to tell the browser not to let a page from a foreign domain read a response. And, in the case of preflight requests, it can ask the browser not to send it certain requests from a foreign domain. But CORS doesn't specify any means for the server to reject (that is, not execute) an actual request.

Let's take an example. A user is logged in to site A via a cookie. The user loads malicious site M, which tries to submit a form that does a POST to A. What will happen? Well, with or without CORS, and with or without M being an allowed domain, the browser will send the request to A with the user's authorization cookie, and the server will execute the malicious POST as if the user initiated it.

This attack is called Cross-Site Request Forgery, and CORS itself does nothing to mitigate it. That's why CSRF protections are so important if you allow requests to change data on behalf of users.

Now, the use of the Origin header can be an important part of your CSRF protection. Indeed, checking it is part of the current recommendation for multi-pronged CSRF defense. But that use of the Origin header falls outside the CORS specification.

In sum, CORS is a useful specification for extending the existing Same Origin Policy security model to other accepted domains. It doesn't add security, and sites need the same kinds of defense mechanisms that they did before CORS.

Answer 6

I am late to answer but I don't think any post here really provides the sought answer. The biggest takeaway should be that the browser is the agent that is writing the origin header value. An evil script cannot write the origin header value. When the server responds back with a Access-Control-Allow-Origin header, the browser tries to ensure that this header contains the origin value sent earlier. If not, it triggers an error and does not return the value back to the requesting script. The other answers to this question present a good scenario to when you would like to deny an answer back to the evil script.

@daniel f also provides a good answer to the question