W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2017

Re: CORS

From: Stefan Zager <szager@google.com>
Date: Wed, 11 Oct 2017 15:48:16 -0700
Message-ID: <CAHOQ7J_-fv2sXasdOPG-XTPPf5tY2Ba9XBQuxkgXjm5RsqC0Gw@mail.gmail.com>
To: "Jack (Zhan, Hua Ping)" <jackiszhp@gmail.com>
Cc: Florian Bösch <pyalot@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
If all of the other experts on this thread have not convinced you, then I
doubt that I will either.  But I'll try...

You seem to assume that the web developers at bankA.com will be very smart
and careful, and never serve private data in response to a cross-origin
request.  But the truth is that not all developers are so careful, and not
all domains are so secure.  In a world of imperfect web sites, same-origin
policy is a huge improvement for the security of the end user, even if it
causes some minor inconvenience to developers.

One of the first things I learned about computer security was this: prefer
white lists over black lists.  A black list means: "I have a list of
resources that should NOT be sent in response to cross-origin requests;
anything that's not on my list should be allowed."  A white list means: "I
have a list of resources that CAN be sent in response to a cross-origin
request; anything that's not on my list should NOT be allowed."

White lists are safer, because if you make a mistake in the list, then the
worst that happens is that you fail to send safe data; but you will never
accidentally send unsafe data.  CORS implements a white list.

I do hope you take the time to read the document about CORS headers that
Travis mentioned: https://w3c.github.io/webappsec-cors-for-developers/.  If
nothing else, it will clarify that the main point of concern here is to
protect the embedded content (the iframe) from a hostile/evil embedder.
Your earlier example about a government agency trying to scan evil
third-party websites is not relevant, and has nothing to do with CORS.
Indeed, if you were the government employee given the job of implementing
such a scanning tool, there are certainly many other (better) ways to
implement it, besides a web page making cross-origin requests.

On Wed, Oct 11, 2017 at 3:00 PM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com>
wrote:

> >> I have already responded this to Tab Atkins as follows:
> > You have not. And I ask again. How do you instruct a browser which
> resource
> > is ok to request from another origin?
> When I said "as follows:", the answer text followed. And I elaborated
> a bit more than asked, and at the end I challenge you to defeat me.
> Please read that or here:
> http://lists.w3.org/Archives/Public/public-webapps/2017OctDec/0024.html
> There is no point for me to copy it here again.
>
> But in one sentence: I do not need the browser to do the authorization
> check for me, I do the authorization check myself at server
> https://bankA.com/.
>
> with best regards
> Jack (Zhan, Hua Ping詹华平)
> +86-153-9230-9232
> QQ: 94544458  欢迎加我,欢迎访问QQ空间
> twitter: https://twitter.com/jackzhp/with_replies
>
>
Received on Wednesday, 11 October 2017 22:48:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 November 2017 09:59:04 UTC