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

Close, Tyler J. wrote:
> 
> Hi Mark,
> 
> Seem to be running into you a lot lately. Just one question...
> 
> Mark Nottingham wrote:
>> On 02/01/2008, at 1:00 AM, Ian Hickson wrote:
>>> On Mon, 31 Dec 2007, Close, Tyler J. wrote:
>>>> 1. Browser detects a cross-domain request
>>>> 2. Browser sends GET request to /1234567890/Referer-Root
>>>> 3. If server responds with a 200:
>>>>    - let through the cross-domain request, but include a
>> Referer-Root
>>>> header. The value of the Referer-Root header is the relative URL /,
>>>> resolved against the URL of the page that produced the
>> request. HTTP
>>>> caching mechanisms should be used on the GET request of step 2.
>>>> 4. If the server does not respond with a 200, reject the
>> cross-domain
>>>> request.
>>> This is a very dangerous design. It requires authors to be able to
>>> guarentee that every resource across their entire server is
>> capable of
>>> handling cross-domain requests safely. Security features with the
>>> potential damage of cross-site attacks need to default to a safe
>>> state on
>>> a per-resource basis, IMHO.
>> Agreed. Some sort of map of the server is needed with this approach.
> 
> The above comment leaves me with the impression that you too think the client
 > should be enforcing the server's access control policy. I just find 
this a
 > really strange position. Ian seems to support this view with the 
perspective
 > that client developers will deploy better software faster than server
 > developers. Is that also your rationale?

You do realize that the current spec lets the server do all the 
enforcement if it so pleases? It can check the relevant headers and 
simply send back an empty document if it does not want to allow access 
to the resource.

It does however have the *option* to let the client do the 
authentication. If it doesn't trust the client to do this correctly all 
the authentication can take place on the server.

/ Jonas

Received on Thursday, 3 January 2008 17:12:26 UTC