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 15:06:01 UTC