Re: CORS

On Tue, Oct 10, 2017 at 3:58 PM, Jack (Zhan, Hua Ping)
<jackiszhp@gmail.com> wrote:
>>> As for Travis's example, should a browser allow http://evil.com/a.html
>>> to access https://bankA.com/somedata?
>
> On Wed, Oct 11, 2017 at 6:12 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> You don't control evil.com, you control bankA.com. You don't want evil.com
>> access bankA.com/mybalance with a data request because it is private
>> information. evil.com could XHR get bankA.com/mybalance and then XHR post it
>> to evil.com/save. The same origin policy that restricts data requests to the
>> same origin solves that problem. But it creates a new problem, how does
>> somesite.com offer resources to use by othersite.com, such as, for instance,
>> twitter. The answer is for somesite.com to offer a permission on a resource,
>> that's what CORS is. evil.com does not control the users computer or UA. If
>> the user chooses to use a browser that does not implement the same-origin
>> policy, that's his choice, it's not a smart choice, because then this
>> bankA.com/mybalance will end up on evil.com/save.
>
> You are a web programmer, and your team are working on
> http://evil.com/a.html. Your task is to get the ticker data of MSFT
> from http://bankA.com/ticker/MSFT and show it to the user who loads
> a.html provided by you. Why the browser should deny a.html to load the
> ticker data?

Because the browser cannot automatically tell what page data contains
sensitive information and what doesn't.  Just because the user visits
evil.com, that does not automatically mean they grant evil.com
permission to access all of their private data on other websites.  (Or
worse - visiting good.com, and an ad from evil.com runs in an iframe
and wants to slurp up all their private information.)

> And I am working for the https://bankA.com/, it is my job to prevent
> you from access protected resources, while you are welcome to use
> public data such as MSFT's ticker data. It is not your job to make
> sure sensitive data on https://bankA.com/ is protected.

As someone who works on browsers, it *is* my responsibility to make
sure that, when it's possible to do so, I protect the user's
information on bankA.com from evil people on evil.com.  There's a lot
of stuff I *can't* do, either because I don't know it's bad, or
"fixing" it will hurt too many other things, but there are some
actions I can take (like applying the same-origin policy, preventing
cross-origin scripts from accessing arbitrary stuff) that help a lot
and hurt fairly little.

> By the way I
> deem CORS is stupid, so I will not serve you the header
> "Access-Control-Allow-Origin "*"". It is your browser stopped you from
> access the public available data from https://bankA.com/, not me.
> Since you did not ask how I prevent you from access confidential data
> on https://bankA.com/, I omit this.

This is you shooting yourself in the foot, then. Browsers block
cross-origin data by default, to protect their users; you can unblock
it with CORS.  If you refuse to use CORS, you can't unblock things.
It's your problem that you're intentionally avoiding the tool that
does what you ask.

~TJ

Received on Tuesday, 10 October 2017 23:19:00 UTC