Current Web security depends on the Web browser "same origin policy",
which says (roughly-speaking) that HTTP requests made from within a
document retrieved from some origin (scheme, host + port) must only be
allowed to the same domain. The reason for this is to avoid a
malicious HTTP request initiated by some origin going to a different
origin - allowing "cross-site request forgery" and other cross-origin
attacks. Such a malicious request is made possible by the inability of
a client to tell that it should not send local shared client state (such as cookies) to a
particular origin when a malicious request is initiated, and the lack
of a user prompt in many of these scenarios (making it impossible for
a user to even see whether something might be going wrong).

The rules for the same-origin policy are not enforced reliably (not,
for example, in the 'src' attribute of a <script> tag - see [CrockScript]),
which has led to the use of techniques which allow cross-domain
requests, such as the widespread use of dynamic script tags and use of
"iframes" to allow multiple documents from several origins to exist
within the same containing document, or JSONP -- all of which may open
further security vulnerabilities.

The Cross Origin Resource Sharing (CORS) specification [CORS] allows
an origin to explicitly opt-in to a model for sharing access to its resources
with a set of other, named, origins - in other words, to intentionally
allow cross-origin requests from a named subset of origins. 
That model may then be used by other
specifications in order to expose cross-origin requests via the
specified APIs. 

One API specified which utilizes CORS is specified in
XMLHttpRequest2 [XHR2].

There is a section of the Web community which claims that the
origin-based access-control model, regardless of the security measures implemented in
the CORS/XHR2 algorithms, is inherently vulnerable to cross-origin
security issues because of its reliance on an identity-based, "ambient
authority" (origin, cookies etc.) model where, because of the presence
of intermediaries, it is impossible with this model to reliably
"authenticate" the origin of a request, yet user credentials (such as
cookies) are sent automatically to a server.

An alternative model, which claims to resolve these issues, is proposed
in the Uniform Messaging Policy specification. That document proposes
an alternative to both CORS (ie. it proposes that an origin server
"opts-in" to requests from all domains, not a named subset controlled
by the client) and XHR2 (UMP proposes a new XHR API that applies the
same policy to same-origin requests as to cross-origin requests). UMP
does not propose a specific access-control mechanism, but expects that
parties involved in a web application will authenticate each other in
ways other than by using origin-based access control, such as by the sharing of
authorization tokens between the parties. One potential multi-party
mechanism is described in [CORSChallenge].

It has been proposed that UMP could form a subset of the CORS
specification (using the 'credentials' flag of CORS). 

It should be noted that because UMP suggests a new model, it does not
yet support the same set of use-cases supported by CORS.

In summary, both CORS and UMP support cross-domain requests. CORS
utilizes existing origin- and cookie-based approaches for access
control, but doesn't completely prevent XSRF/Clickjacking. UMP allows
the complete prevention of such attacks, but relies upon
relatively non-standard mechanisms for authenticating cross-site requests in
order to do so. UMP and CORS differ in the use-cases they support. 


- johnk

[CORS/UMP] Begins with:
[UMP/CORS:Implementor Interest] Begins with:
[[UMP] Request for Last Call]

Received on Thursday, 20 May 2010 15:01:32 UTC