RE: [webappsec] Updated proposal for CORS security considerations

Looks great to me.  Thanks, Anne.  A few folks wanted a bit more time to review this on the call today, so will take up a formal resolution to go to LC on the next call.

-Brad

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@opera.com]
> Sent: Tuesday, February 14, 2012 7:05 AM
> To: public-webappsec@w3.org; Hill, Brad
> Subject: Re: [webappsec] Updated proposal for CORS security considerations
> 
> Thanks for writing this. I integrated this though not completely. See below
> for details.
> 
> http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html

> 
> 
> On Tue, 07 Feb 2012 00:03:49 +0100, Hill, Brad <bhill@paypal-inc.com>
> wrote:
> > 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.
> 
> I removed the second header as there is no such value and it is not needed.
> 
> 
> > 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.
> 
> Not sure if we need to include this. Everyone supports CORS and this section
> is already pretty long. Commented out for now.
> 
> 
> > 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.
> 
> I changed since as comments are protected currently and JSON cannot be
> executed and therefore not read cross-origin.
> 
> 
> > 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.
> 
> This is wrong. CORS always uses the actual origin, not the effective origin.
> 
> 
> > 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.
> 
> I guess this point is valid.
> 
> I commented out part 3 for now, but we should maybe include the above
> paragraph somehow.
> 
> 
> --
> Anne van Kesteren
> http://annevankesteren.nl/

Received on Tuesday, 14 February 2012 23:21:00 UTC