Re: ACTION-340: CORS, UMP and XHR2

On Thu, May 20, 2010 at 7:57 AM, John Kemp <john@jkemp.net> wrote:

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


UMP does support the use cases listed in the CORS doc, and virtually all use
cases anyone has thrown at us. Also, CORS does not support many of the use
cases supported by UMP. This pair of facts seem worth mentioning.



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


As we explain in the "Security Considerations" of UMP, websites must already
use some kind of unguessable token (i.e., the CSRF token) to protect
themselves from CSRF anyway. So UMP does not rely on "relatively
non-standard mechanisms". Am I missing something?




> UMP and CORS differ in the use-cases they support.
>

The only differences I know of, and that has withstood any scrutiny, are
that UMP supports some use cases that CORS does not.



>
> Regards,
>
> - johnk
>
> [CORS] http://www.w3.org/TR/access-control/
> [UMP] http://www.w3.org/TR/UMP/
> [XHR2] http://www.w3.org/TR/XMLHttpRequest2/
> [SOP] http://en.wikipedia.org/wiki/Same_origin_policy
> [AmbientAuthority] http://en.wikipedia.org/wiki/Ambient_authority
> [CORSChallenge]
> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0479.html
> [CORS/UMP] Begins with:
> http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP
> [UMP/CORS:Implementor Interest] Begins with:
> http://www.mail-archive.com/public-webapps@w3.org/msg08280.html
> [[UMP] Request for Last Call]
> http://www.mail-archive.com/public-webapps@w3.org/msg08135.html
> [CrockScript] http://javascript.crockford.com/script.html
>
>
>


-- 
    Cheers,
    --MarkM