RE: CORS

Let me point you to Brad Hill's write-up on CORS, which is an excellent explanation of the "how" and "why" of its design: https://w3c.github.io/webappsec-cors-for-developers/



-----Original Message-----
From: Jack (Zhan, Hua Ping) [mailto:jackiszhp@gmail.com] 
Sent: Tuesday, October 10, 2017 12:48 PM
To: Travis Leithead <travis.leithead@microsoft.com>; pyalot@gmail.com; public-webapps@w3.org; Anne van Kesteren <annevk@annevk.nl>
Subject: Re: CORS

Travis Leithead <travis.leithead@microsoft.com> wrote:
>While the Adobe solution you mention below seems OK at first, note that 
>the requestor for permissions is self-granting the permission. In other 
>words, it would be just as easy for: https://evil.com/ to add <meta 
>name="sameOrigin" content="https://popularbank.com" /> and grant 
>permission to itself to access your bank. A self-granting permission model just isn't secure--the permission grant must come from the resource being requested.

Florian Bösch <pyalot@gmail.com> wrote:
>Was about to point that out. Never heard about Adobes approach, but 
>you'd think that overtime Adobe would get security right. Apparently not.

At first, thank you for responding to what I wrote.

Clearly you two messed up the extension of the same site/origin policy with the resource access authorization. You even got your purpose wrong. As for your example, your sole purpose on extending same site/origin policy is to extend the capability of https://evil.com/a.html while keeping the evil from being poisoned. As for your example, your purpose is "not to protect the bank", but to extend the capacity of the evil to guarantee the evil can do its evil thing. How to protect the resource at https://bankA.com/ is another issue. Its protection should not rely on how to extend the capability of https://evil.com/ while keep the evil from being poisoned.


Travis is working for Microsoft, what you said surprised me. For many times, I felt powerless to clarify some simple things. This is one incident of it, let me try to put it this way:
Suppose you are working as a CIA field data
analyst(https://evil.com/agentA.html) within US government(browser).
In the old days the same site/origin policy allows you to analyze only files from CIA(https://evil.com/). We all know that you should be allowed to analyze files from any where as long as you need it, such as files from a terrorist office(https://bankA.com/ a terrorist disguises as a banker), so we have to extend the same site/origin policy to allow you (agentA.html) to access any file as you needed after the government assigns you the job(browser load the page agentA.html).

Here, the security issue is how the US government(browser) should protect you (agentA.html) from being poisoned/killed by files from any terrorist's office. The script element approach(JSONP) would give a terrorist the opportunity to poison you through the files. So a dedicated approach for CORS data fetch is indeed needed.

The wrong of W3C CORS/fetch is to design a system which puts a note on every file folder saying that who with what kind of method can access it. And the US government(browser) imposes the rules stated by the note when it(government) fetches the file for you(agentA.html). Isn't this US government and the W3C's recommendation stupid?

And what you two said is that permission for you(agentA.html) to analyze files from terrorist's office should be granted by the note on the file folder, isn't it totally nonsense? I guess you two are not working on computer security.

I am looking forward to responses from people who think they really understand the issue. If you do, please comment.

with best regards
Jack (Zhan, Hua Ping詹华平)
+85-153-9230-9232
QQ: 94544458  欢迎加我，欢迎访问QQ空间
twitter: https://twitter.com/jackzhp/with_replies

Received on Tuesday, 10 October 2017 21:45:48 UTC