Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Thu, Dec 17, 2009 at 5:49 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 17 Dec 2009, Tyler Close wrote:
>>
>> Starting from the X-FRAME-OPTIONS proposal, say the response header
>> also applies to all embedding that the page renderer does. So it also
>> covers <img>, <video>, etc. In addition to the current values, the
>> header can also list hostname patterns that may embed the content. So,
>> in your case:
>>
>> X-FRAME-OPTIONS: *.example.com
>> Access-Control-Allow-Origin: *
>>
>> Which means anyone can access this content, but sites outside
>> *.example.com should host their own copy, rather than framing or
>> otherwise directly embedding my copy.
>
> Why is this better than:
>
>   Access-Control-Allow-Origin: *.example.com

X-FRAME-OPTIONS is a rendering instruction and
Access-Control-Allow-Origin is part of an access-control mechanism.
Combining the two in the way you propose creates an access-control
mechanism that is inherently vulnerable to CSRF-like attacks, because
it determines read access to bits based on the identity of the
requestor.

Using your example, assume an XML resource sitting on an intranet
server at resources.example.com. The author of this resource is trying
to restrict access to the XML data to only other intranet resources
hosted at *.example.com. The author believes this can be accomplished
by simply setting the Access-Control-Allow-Origin header as you've
show above, but that's not strictly true. Every page hosted on
*.example.com is now a potential target for a CSRF-like attack that
reveals the secret data. For example, consider a page at
victim.example.com that uses a third party storage service. To copy
data, the page does a GET on the location of the existing data,
followed by a POST to another location with the data to be copied. If
the storage service says the location of the existing data is the URL
for the secret XML data (http://resources.example.com/...), then the
victim page suffers a CSRF-like attack that exposes the secret data.
The victim page may know nothing of the existence or purpose of the
secret XML resource.

To avoid this pitfall, we instead design the access-control mechanism
to not create these traps. With the bogus technique removed, the
author of a protected resource can now choose amongst techniques that
actually work.

To address your bandwidth stealing concerns, and other similar issues,
we define X-FRAME-OPTIONS so that a resource author can inform the
browser's renderer of these preferences. So your XBL resource can
declare that it was only expecting to be applied to another resource
from *.example.com. The browser can detect this misconfiguration and
raise an error notification.

By separating the two mechanisms, we make the access-control model
clear and correct, while still providing the rendering control you
desired.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Monday, 21 December 2009 18:27:00 UTC