Dubious purpose of the same origin policy

问题:

As I read, the same origin policy is about preventing scripts with origin in (evil) domain A to make requests to (good) domain B - in other words cross-site request forgery.

Playing around a bit I learned about Access-Control-Allow-Origin header and CORS which, as I somehow understand, allows to specify server from the good domain B that the domain A is an allowed origin (therefore not evil) . If this header is not present in the cross-domain response, the browser will not to read anything from it, but it has already made request anyway.

Now, I am somehow missing the point here. If domain B has a web services API and the cookie authentication with the user being logged in, basically any operation can be performed on the poor user's behalf by the evil origin A, just the attacker won't see the response.

What am I missing here? Where is my reasoning faulty?

回答1:

As I read, the same origin policy is about preventing scripts with origin in (evil) domain A to make requests to (good) domain B - in other words cross-site request forgery.

The Same Origin Policy prevents a mismatched domain, port or protocol combination reading from another origin. It says nothing about restricting requests from being made in the first place.

e.g.

• http://www.example.com cannot read anything on http://www.example.edu
• https://www.example.com cannot read anything on http://www.example.com (except cookies, as the Same Origin Policy for cookies is different)
• http://www.example.com:8080 cannot read anything on http://www.example.com

The Same Origin Policy does not prevent a request being made to another domain. It is only the response that is read only. So...

• http://www.example.com could POST data to http://www.example.edu via AJAX or form (even with credentials if 3rd party cookies are enabled in the browser)
• http://www.example.com could POST data to https://www.example.com via AJAX or form
• As far as the Same Origin Policy is concerned, https://www.example.com could POST data to http://www.example.com although the browser will more than likely either block the request or warn the user as HTTP content is accessed over a HTTPS page. Definitely when via AJAX, via form will depend on the browser and settings
• http://www.example.com could load an image from http://www.example.edu, however the image data will not be available via scripting

So CORS does not relax the security of what was already possible, it allows a domain to opt into CORS and allows another domain to read responses from it.

回答2:

CORS doesn't prevent anything that was allowed before CORS was invented. It only specifies a way for sites to allow requests that were previously always denied.

One site could always cause a user agent to make requests to other sites, since the beginning of the Web. Just think hotlinked images.

Typically, it's not correct for a site to authorize an action just based on a cookie, because, as you point out, any site can make requests using other sites' cookies.

A site will usually require that the request contain something other than the cookie. It might, for example, look for a CSRF token that must be read from a previous response. As site B, you'd need use CORS to obtain this token.