Re: Comments on: Access Control for Cross-site Requests

Jonas Sicking wrote:
> 
> John Panzer wrote:
>>
>> Jonas Sicking wrote:
>>> John Panzer wrote:
>>>> Some comments on blocking of authentication credentials:
>>>>
>>>>     When making a cross-site access request
>>>>     
>>>> <http://dev.w3.org/2006/waf/access-control/#cross-site-access-request>,
>>>>     user agents /should/ ensure to:
>>>>     "Not allow the author to set cookies or authentication credentials
>>>>     for the request, as this would allow for a distributed cookie or
>>>>     credentials search."
>>>>
>>>> and
>>>>
>>>>     Why can cookies and authentication information /not/ be provided by
>>>>     the script author for the request?
>>>>
>>>>         This would allow dictionary based, distributed, cookies / user
>>>>         credentials search.
>>>>
>>>> There are schemes for Authorization: which do not use passwords and 
>>>> therefore do not have a dictionary attack problem; one of them is 
>>>> OAuth (http://oauth.net).  It uses the Authorization: header by 
>>>> preference and can be used within a browser.  (OpenSocial is in fact 
>>>> currently relying on OAuth for authorization of proxied cross-site 
>>>> requests.)
>>>>
>>>> Is the intent to block the use of Authorization: headers completely, 
>>>> or only the use of Authorization: Basic and the like?  If the 
>>>> former, I suggest that hindering the use of newer, more secure 
>>>> mechanisms for authentication reduces security rather than enhancing 
>>>> it.
>>>
>>> Authorization headers are still sent. However only the authentication 
>>> credentials that the user has already used to log into the site is sent.
>> That's the problem.  One of the major reasons for OAuth is to allow 
>> delegated authorization (I authorize site X to access my data on site 
>> Y).  Javascript code to do the mechanics already exists 
>> (http://oauth.googlecode.com/svn/code/javascript/v2/) and could be 
>> used on a page of site Y, if the page is allowed to access site X at 
>> all.  I don't think anyone expects built-in browser support for OAuth 
>> or other schemes, but the current proposal actually hinders use of 
>> these schemes by Javascript.
> 
> I quick look at OAuth and it looks like authentication is simply done 
> using the body of HTTP messages (primarily POST). Is that correct? If so 
> I don't see anything that should stop this from working with the spec 
> as-is. If this is wrong, could you please elaborate on what in the spec 
> makes OAuth impossible and how we could fix it.

My Misstake. I see that OAuth indeed uses the "Authorization" header.

Unfortunately I don't see a way we could allow setting that header 
without also making it possible to perform directory based attacks. In 
general it would be opening a can of worms to let you set this header 
since there might be important user data in cookies, or maybe elsewhere. 
So the server would get authorization data for one account, but cookie 
data for another.

I guess we could add support for more negotiation between the client and 
server to not just negotiate supported http-methods, but also support 
other capabilities. However I'm very reluctant to add support for that 
at this point and would rather see that in a version 2 of the spec.

/ Jonas

Received on Tuesday, 5 February 2008 10:42:19 UTC