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 19:48:35 UTC