[webappsec] Updated proposal for CORS security considerations

Following further consideration, I have updated my proposed security considerations text for CORS around avoidance of confused deputy vulnerabilities when using implicit credentials.

The new text follows; comments, additions and improvements welcome.

Thanks,

Brad Hill

--------

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 expect 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 [CSARF] by requiring the inclusion of 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 requiring the inclusion of 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.

i. Authorization for a request should be performed using only the intersection of the authority of the user and the requesting origin(s).  In the case of redirects, more than one value for Origin may be present and all must be authorized.

ii. Servers using the Origin header to authorize requests must also verify the Host header matches its expected value to prevent forwarding attacks.  Consider two sites, "www.example-a.com" and "www.example-b.com".  A web application at "www.example-a.com" makes a cross-origin request to "www.example-b.com", and the user-agent sends the Origin header "www.example-a.com".  If "www.example-b.com" or the network is malicious, it may cause the request to be delivered to "www.example-a.com", with the result that "www.example-a.com" would receive a requst that appears to originate from itself.  Verifying the Host header would reveal that the user-agent intended the request for "www.example-b.com" and it can be discarded.  It is also recommended that servers use HTTPS targets for cross-origin requests to enable the user-agent to detect such misdirections.

iii. It is often appropriate for servers to require an authorization ceremony asking a user to consent that cross-origin requests with credentials be honored from a given origin.  In such cases, passing security tokens explicitly as part of the cross-origin request can remove any ambiguity as to the scope of authorization.  See [OAuth] for an example of this pattern.

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], or [postMessage].

This substitution may expose additional attack surface in some cases, as a cross-site scripting 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 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 must validate that data received from origins that are not completely trusted conforms to expected formats and authorized values.

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.  Again, data received from origins that are not completely trusted must be validated to conform to expected formats and authorized values.

ii. For resources that are safe and idempotent [HTTP], 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 to ensure that effects implied do not exceed the authority of the originating principal.

Given the difficulty of avoiding such vulnerabilities in multi-party interactions it is recommended that, instead of using implicit credentials, security tokens which specify the particular capabilities and resources authorized be passed explicitly as part of each request. [OAuth] provides an example of this type of pattern.



[CSRF] http://marc.info/?l=bugtraq&m=99263135911884&w=2  Cross-Site Request Forgeries, P. Watkins. Bugtraq, 15 June 2001.
[ECMAScript] http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf ECMA-262: ECMAScript Language Specification, third edition, ECMA. December 1999.
[JSON] http://www.ietf.org/rfc/rfc4627.txt The application/json Media Type for JavaScript Object Notation (JSON), D. Crockford. IETF, July 2006.
[OAuth] http://tools.ietf.org/html/rfc5849 The OAuth 1.0 Protocol, E. Hammer-Lahav, Ed., April 2010
[JSONP] http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/ Remote JSON - JSONP: JSON with Padding, Bob Ippolito, December 2005
[postMessage] http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging, Ian Hickson, Ed., January 2012
[HTTP] http://www.ietf.org/rfc/rfc2616.txt RFC 2626: Hypertext Transfer Protocol -- HTTP/1.1, Section 9.1, Fielding, et al., June 1999
[Confused Deputy] http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html, Norm Hardy