- From: John Kemp <john@jkemp.net>
- Date: Thu, 20 May 2010 10:57:39 -0400
- To: "www-tag@w3.org WG" <www-tag@w3.org>
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. 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
Received on Thursday, 20 May 2010 15:01:32 UTC