Re: CORS

CORS solves a problem (how to let other sites access resources on your
site) that exists because browsers implement the same-origin policy on data
requests. The same origin policy exists because some data (
mysite.com/balance) might be sensitive or because some handler (
mysite.com/delete-user) might have side effects, and because any form of
authentication (cookies, http-auth, etc.) is attached to a request to that
origin.

CORS does this by marking up resources with permissions. This is an
effective solution because an attacker has an interest in gaining the
credentials of a logged in user residing in their UA and using them to
perform malicious acts. The attacker does not control the users UA. It is a
precise mechanism because the site that implements those resources has the
knowledge about which are sensitive and which have side effects, and which
it wants to share.

On Tue, Oct 10, 2017 at 5:06 PM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com>
 wrote:
>
> Adobe's solution to this was invented long ago, and I would say it is
> elegant. As for the above example, what is needed is simply for
> abc.html to add a piece of meta data:
> <meta name="sameOrigin" content="http://2nd.com/"/>
> or with an HTTP header when serving abc.html:
> SameOrigin: http://2nd.com/


This self-grants permission of 2nd.com to resources from 1st.com. That
circumvents the intent of the same origin policy which aims to protect
users from malicious sites.


> Frankly speaking with simple language, I feel that either I am simply
> & totally wrong/stupid

Correct.


> Any respond is appreciated.
>
I come to doubt that.

On Tue, Oct 10, 2017 at 9:48 PM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com>
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.
>

This made no sense whatsoever. The same origin policy exists to protect
resources of one site, from access by another site, because those resources
might sensitive or have side effects. CORS exists to allow sites to share
resources for use by other sites. CORS achieves that by tagging resources
with permissions of use by the originating site, and in that, perfectly
achieves its aim.

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.
>

This again made no sense at all.


> 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?
>

Apart from this making no sense at all either, it seems to suggest marking
up permissions for resources that need permissions is supposed to be
stupid. Somehow that seems a flawed kind of "logic".


> 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.
>

It's amazing that somebody who exhibits this little understanding of the
issue at hand insinuates stupidity and incompetence in everybody who
responds and then has the gall to...

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

Claim to look forward to more responses.