[webappsec WG] Security Considerations for CORS with credentials

In response to the Call for Consensus to move CORS to Last Call, a discussion and objections have arisen on the TAG list this last week.  To summarize, Mark Miller and Tyler Close feel that ISSUE-108 in WebApps has not been adequately addressed: http://www.w3.org/2008/webapps/track/issues/108?changelog

In the course of a few emails, we've arrived at the following "challenge" from Miller and Close:

Tyler Close:

"For the Security Considerations section, the main goal was not to
produce text that developers would read. The goal of the exercise was
to prove to ourselves that there exists a simple set of rules that can
be followed to safely use CORS with credentials. If the WG is unable
to produce such rules, that indicates the design is flawed and should
be reconsidered."

Mark Miller:

"As Dean Tribble says, "There's nothing so clear as a vague idea you haven't written down yet." I believe the main antidote offered for the CORS confused deputy problems, DBAD ("Don't be a deputy"), is such a vague idea. I doubt it is coherent. But it seems the only way to convince anyone is to get its advocates to state it explicitly enough that it can be examined. We should see whether it survives this exercise."

Specific example vulnerabilities are discussed at: http://sites.google.com/site/guestxhr/maciej-challenge and http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html.


Though this is an issue that has been previously discussed to a stalemate in WebApps, I think perhaps WebAppSec can bring a different set of experience to this challenge.   I understand the issues they raise, but to my view the issues with cross-origin ambient authority are part of the general architecture of the Web.  CORS does not solve them, but it does not make them worse, and it provides substantial security improvements on existing patterns.  My attempt at a security considerations section which would address these concerns directly is below. (with much text taken from the security considerations section of Miller and Close's UMP draft)

What do folks think?

Security Considerations:

1.            Simple cross-origin requests in this specification have been defined as congruent with those which may be generated by currently deployed user-agents that do not conform to this specification.  Simple cross-origin requests generated outside this specification (such as cross-origin form submissions using GET or POST or cross-origin GET requests resulting from <script> tags) typically include credentials, so resources conforming to this specification must always be prepared to accept simple cross-origin requests with credentials.

Because of this, resources for which simple requests have significance other than retrieval must protect themselves from Cross-Site Request Forgery by including an unguessable token in the explicitly provided content of the request.

2.            This specification defines how to authorize an instance of an application from a foreign origin, executing in the user-agent, to access the representation of the resource in an HTTP response.  Certain types of resources should not attempt to specify particular authorized origins, but instead either deny or allow all origins.

a.            A resource that is not useful to applications from other origins, such as a login page, should not return an Access-Control-Allow-Origin header. The resource still must protect itself against CSRF attacks, such as by including an unguessable token in the explicitly provided content of the request. The security properties of such resources are unaffected by user-agents conformant to this specification.

b.            A resource that is publicly accessible, with no access control checks, should always return an Access-Control-Allow-Origin header with the literal string "*" as its value and an Access-Control-Allow-Credentials header with the literal string "false" as its value.

Legacy user-agents remain limited by the Same Origin Policy from accessing such resources cross-origin. Currently deployed user-agents that understand the Access-Control-Allow-Origin header, as well as user-agents conformant to this specification, will be able to access such resources regardless of origin.

c.             A GET response whose body happens to parse as [ECMAScript] should always return an Access-Control-Allow-Origin header with the literal string "*" as its value. This category includes [JSON] content. These responses have already effectively opted-out of Same Origin Policy protection, since the content can be accessed cross-origin using an HTML <script> tag. If needed, such resources should implement access control and CSRF protections as described in Part 1 of these considerations.


3.            Certain precautions should be followed when specifying particular authorized origins in the Access-Control-Allow-Origin header:

a.            Authors should be aware that an application executing in the user-agent is allowed to reduce the specificity of its origin by modifying the document.domain property to a less-specific value.  (e.g. from foo.example.com to example.com) Therefore the scope of an access grant implicitly includes not just the named origin, but more specific ones beneath it in the DNS hierarchy.

b.            User-agents often restrict the degree to which the specificity of an origin can be reduced, typically using a "public suffix" list to forbid any resource from having a host portion that is a part of the DNS hierarchy controlled by a public registry. (such as "com", "co.uk", and "pvt.k12.wy.us")  Although these lists are difficult to keep up to date and vary between implementations, resources SHOULD NOT return an Access-Control-Allow-Origin header with a host value whose domain is a public suffix, as such an origin is impossible to match securely.

c.             Origins with schemes that do not provide authentication (e.g. http) and origins with an unqualified name in the host portion, (e.g. 'example') including origins with unqualified names in the https scheme, (e.g. 'https://example/') do not provide secure identification of the requesting application. Caution should be taken before granting applications from such origins access to confidential or protected resources.

4.            Care must always be taken by applications when making cross-origin requests with credentials, and servers processing such requests must take care in the use of credentials, including the Origin header.

a.            When requests have significance other than retrieval, and when relying on the Origin header as a credential, servers must be careful to distinguish between authorizing a request and authorizing access to the representation of that resource in the response.

b.            Use of credentials in a cross-origin request is appropriate when:

i.              A cross-origin request with credentials as defined in this specification is used to substitute for alternate methods of authenticated resource sharing, such as server-to-server back channels, JSONP, postMessage or IFRAME side-channels.

This substitution may expose additional attack surface in some cases, as a cross-site scripting [TODO: REF] vulnerability in the requesting origin may allow elevation of privileges against the requested resource when compared to a server-to-server back channel.

As a substitute for JSONP-style [TODO: REF] cross-origin credentialed requests, use of this specification significantly improves the security posture of the requesting application, as it provides cross-origin data access whereas JSONP operates via cross-origin code-injection.  The requesting application should still take care to validate data received from origins that are not completely trusted.

As a substitute for cross-origin communication techniques relying on loading a resource, with credentials, into an IFRAME, and subsequently employing postMessage or other cross-origin side channels, this specification provides a roughly equivalent security posture.

ii.             For resources that are safe and idempotent, [TODO: REF] and where the credentials are used only to provide user-specific customization for otherwise publicly accessible information.  In this case, restricting access to certain origins may protect user privacy by preventing customizations from being used to identify a user, except at authorized origins.

c.             When this specification is used for requests which have significance other than retrieval and which involve coordination between or data originating from more than two origins, (e.g. between resources enabling editing, printing and storage, each at distinct origins) requests SHOULD set the credentials flag to "false" and servers SHOULD perform authorization using security tokens explicitly provided in the content of the request, especially if the origins are not all mutually and completely trusted.

In such multi-origin scenarios, a malicious resource at one of the origins may be able to enlist the user-agent as a Confused Deputy and elevate its privileges by abusing the user's ambient authority.  Avoiding such attacks requires that the coordinating applications have explicit knowledge of the scope of privilege for each origin and that all parameters and instructions received are carefully validated at each step in the coordination.

Such vulnerabilities may be more easily avoided by passing, explicitly in each request, security tokens which specify the particular capabilities and resources authorized. OAuth [TODO: REF] provides an example of this type of pattern.



--Brad Hill