Re: Mozilla security review of Access Control

Close, Tyler J. wrote:
> Jonas Sicking wrote:
>> Close, Tyler J. wrote:
>>> Sending the user's credentials without the user's consent
>>> creates a host of security problems, such as the one around
>>> headers the WG is currently struggling with and the one's
>>> I've written about on this list recently, without enabling
>>> any actually viable designs. For example, if the user's
>>> credentials are not used, and the target resource has to
>>> opt-in, it is OK to let the third-party web page specify
>>> whatever headers it wants, so long as the HTTP request is
>>> still well formed, since the third-party could have sent just
>>> such a request from its own machine.
>> All these problems exist even if we don't send cookies. The reason is
>> intranet servers behind firewalls. These sites authenticate simply
>> through the users ability to connect to the server.
> 
> Note that I included the clause ", and the target resouce has to opt-in," to catch the case of an intranet server that relies solely on the client's IP address to authenticate the client.

Right, and this applies if we're sending cookies too.

>> I've argued this in the past (in a discussion on JSONRequest vs. AC
>> iirc), that disabling cookies doesn't actually buy any reliably
>> protection, but it does risk giving us (spec writers) a false sense of
>> security.
> 
> Since not sending cookies does protect services that operate on the open Internet, it is a great exageration to say this measure "doesn't actually buy any reliably (sp) protection". A great number of valuable services are given clear protection by this measure.

I would still say it doesn't buy us any reliably protection. There are 
no changes we can make to the spec if we say that cookies should not be 
sent. For example it doesn't make it any safer to send custom headers, 
and it doesn't make it any safer to use unsafe methods when connecting 
to the server.

The only thing it does buy us is that it protects a lot (but not all) 
servers that are misconfigured by server operators that have 
misunderstood the spec.

> To date, no one has presented a viable design that uses the user's cookies in a cross-domain request. There is a reason for that. It would be a neat trick indeed to claim you were enforcing the user's wishes, without ever getting any expression of those wishes from the user. Automatically sending cookies is a way of bypassing the step of getting the user's consent, when getting the user's consent is a necessary step in enforcing the user's wishes.

I can see several designs where sending cookies is beneficiary and safe. 
First of all cookies doesn't have to be used for authentication, it can 
be used simply as a way to track a session. So if the requesting site 
makes several connections to the target server, the target server can 
keep track of which ones come from the same session.

Another scenario is when there really is full trust between two servers. 
For example www.google.com and www.youtube.com are both run by the same 
company and so transferring user data between the two is no more of a 
privacy issue than giving you data too google.com in the first place.

For mashups, the scenario that I think would be the most useful is if 
sites that hold personal information provide a way for users to 
whitelist which mashup sites they trust with their personal information. 
So they could host a page where i simply list the domains that I want to 
give access to my personal information. When a mashup site then makes a 
request to google they can reply with a 'allow' rule that lists those 
domains.

I'm sure Hixie has lots more safe scenarios where google had planned to 
use Access-Control

/ Jonas

Received on Saturday, 23 February 2008 00:16:50 UTC