W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: Feedback on Access Control

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Wed, 23 Jan 2008 09:14:26 +1100
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-Id: <CDF68063-FD92-4D86-84FF-9E2B51F9917C@yahoo-inc.com>
To: Anne van Kesteren <annevk@opera.com>


On 22/01/2008, at 8:59 PM, Anne van Kesteren wrote:

> On Tue, 22 Jan 2008 04:56:52 +0100, Mark Nottingham <mnot@yahoo-inc.com 
> > wrote:
>> 1) The Method-Check protocol has potential for bad interactions  
>> with the HTTP caching model.
>>
>> Consider clients C and C', both using a caching intermediary I, and  
>> accessing resources on an origin server S. If C does not support  
>> this extension, it will send a normal GET request for a resource on  
>> S, whose response may be cached on I. S may choose to not send an  
>> Access-Control header for that response, since it wasn't "asked  
>> for." If C' does support this extension, it will retrieve the  
>> original response (intended for C) from I, even though it appended  
>> the Method-Check header to a request, and will be led to believe  
>> that the resource on S doesn't support cross-site requests.
>>
>> Three different solutions come to mind immediately;
>>   a) require all responses to carry an Access-Control directive,  
>> whether or not the request contained a Method-Check header, or
>>   b) require all responses to carry a Vary: Method-Check header,  
>> whether or not the request contained a Method-Check header, or
>>   c) remove the Method-Check request header from the protocol, and  
>> require an Access-Control directive in all GET responses.
>>
>> My preference would be (c), because...
>
> I don't understand this comment. The authorization request is the  
> only request that uses the Method-Check HTTP header and that request  
> uses the OPTIONS HTTP method.

Ah, I missed this change in the ED (but now do remember people talking  
about it). Good, that obviates a lot of the issues.


>> [...] Separate from the server-side vs. client-side policy  
>> enforcement issue (which I'm not bringing up here explicitly, since  
>> it's an open issue AFAICT, although the WG doesn't link to its  
>> issues list from its home page), the Working Group needs to  
>> motivate the decision to have access control policy only apply on a  
>> per-resource basis, rather than per resource tree, or site-wide.
>
> It's not an open issue.

Let's have one, then. The W3C has already solved the problem of site- 
wide metadata once, and there should be *some* reason for taking a  
different path this time.


>> Overall, this approach doesn't seem well-integrated into the Web,  
>> or even friendly to it; it's more of a hack, which is puzzling,  
>> since it requires clients to change anyway.
>
> I don't really understand this. Changing clients is cheap compared  
> to changing all the servers out there.

Spoken like a true browser vendor. The thing is, it's not necessary to  
change all of the servers; anyone who's sufficiently motivated to  
publish cross-site data can get their server updated, modified, or  
move to a new one easily. OTOH they have *no* power to update their  
users' browsers (unless they're in an especially iron-fisted  
enterprise IT environment, and even then...).


>> 6) As far as I can tell, this mechanism only allows access control  
>> on the granularity of an entire referring site; e.g., if I allow  
>> example.com to access a particular resource, *any* reference from  
>> example.com is allowed to access it.
>>
>> If that's the case, this limitation should be explicitly mentioned,  
>> and the spec should highlight the security implications of allowing  
>> multi-user hosts (e.g., HTML mail sites, picture sharing sites,  
>> social networking sites, "mashup" sites) to refer to your data.
>>
>> Also, section 4.1 contains "http://example.org/example" as a sample  
>> access item; at best this is misleading, and it doesn't appear to  
>> be allowed by the syntax either.
>>
>> That's all for now,
>
> Multi-user hosts already need filtering. Otherwise they could simply  
> load a page from the same domain with a different path in an  
> <iframe> or something and do the request from there. The security  
> model of the Web is based around domains. How unfortunate or  
> fortunate that may be.

Yes; it's still worth pointing this out for the uninitiated.


--
Mark Nottingham       mnot@yahoo-inc.com
Received on Tuesday, 22 January 2008 22:15:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC