Re: To cookie or not to cookie

Jonas Sicking wrote:
>
> Always forgetting something... Please reply to this one to keep a few 
> mozilla folks in the loop that aren't on the mailing list.
>
> Jonas Sicking wrote:
>>
>> Hi All,
>>
>> During the security review of access control last tuesday at mozilla the
>> issue of weather or not to send cookies and auth headers.
>>
>> Below I will simply use 'cookies' to refer to 'cookie headers and
>> authentication headers' for ease of reading.
>>
>>
>> There are obvious feature advantages to sending cookies. For example it
>> allows mashups where a users private data is used. For example a mashup
>> site that combines a users personal calendar at google.com/calendar
>> could be mashed up with upcoming concerts from livenation.com. As long
>> as the user is logged in to google.com prior to visiting the mashup site
>> this could be done automatically. Similarly linkedin.com could pull in
>> my yahoo mail address book in order to populate my list of contacts, as
>> long as the user has logged in to yahoo mail first.
Note that this is also extremely fragile -- if the user is _not_ logged 
in, the mechanism fails, and you have to devise some way to let the user 
log in and return back to the mashup context seamlessly.  In many cases 
you'd also want to do something different on the mashup side if the user 
is logged in or not, and you can't do that without an additional 
non-cookie inquiry mechanism.
>>
>>
>> There are however security concerns with automatically sending cookies.
>>
>> One concern we found was that it makes it very easy for a site to
>> accidentally grant access to a users personal data without realizing
>> this is done without the users consent. I.e. the worry is that server
>> administrators will think that just because a request includes a users
>> cookies, that the user has authorized the request. To use the examples
>> above:
>>
>> Google could add a rule like 'allow <*>' to let anyone use their
>> calendar APIs. However, if a user visits an evil site, the evil site
>> would then be able to read the users full calendar without any consent
>> at all from the user.
In this case, cookies could be used to identify the user but as you 
point out they're no evidence that the user authorized the evil site to 
access the data.

If Google trusted a site to vouch for user consent, it could either do 
an allow-restrict or it could do a remote site check.  In practice, 
since some calendars are publicly readable while others are private, 
I''m guessing Google would probably opt to use 'allow <*>' and then do 
fine-grained access control within the server logic.  But for publicly 
readable calendars you don't need user identification.

If Google wants to allow users to authorize sites on their own, then a 
separate mechanism for user authorization, such as AuthSub or OAuth, is 
needed.  In these cases the authorization tokens can provide 
identification if necessary, and I think any cookies would be superfluous.

>>
>> Similarly, yahoo mail could add a rule like 'allow <linkedin.com>' since
>> linkedin at the time always asks the user before loading the users
>> address book. However later linkedin.com might decide to change their
>> policy and automatically pull in the users address book without asking
>> the user, or even decide to pull in the address book use it to market
>> their site.
>>
>> In both these cases the problem is definitely google or yahoo 
>> configuring their servers wrong. They should not add 'allow' rules 
>> for sites that they don't trust. The argument is that this is an easy 
>> mistake to make.
Per above, I don't see the 'allow' rule as more than a safety net 
backing up additional finer-grained mechanisms.  In some cases, e.g., 
between blogger.com and google.com, you could base everything on the 
site.  In the most interesting cases you can't.

>>
>>
>> But there are also security concerns with not sending cookies too. The
>> requesting site would have to ask the user for some credential that can
>> then be used to authenticate the user at the target site. There is a big
>> risk that this is often going to be the users normal username and
>> password since anything else is going to be more inconvenient for the
>> user (such as redirecting to the target site and ask the user to fetch a
>> one-time login which is copy/pasted to the requesting site).
Note: Our hope is that the adoption of standardized mechanisms such as 
OAuth will eliminate the need for third parties to ask users for their 
usernames and passwords, which is a major long-term security problem.
>>
>> This both exposes the user to a greater risk since the requesting site
>> is actually given the credential, and also risks creating a culture
>> where people give out their passwords to other sites.
>>
>> Again here you can make a strong case that the user should not give 
>> his/her password to a site that they don't trust. But users make 
>> mistakes too. And the argument is that we're forcing a culture where 
>> users give out their credentials making that seem more normal to them.
...
>>
>> The risk of not sending cookies is that it can create a culture where
>> people give out their passwords to other sites.
>>
>> Another way of looking at it is that there are 3 parties involved in 
>> an Access-Control request. The requesting site, the target site and 
>> the user. Access-Control enforces that two of the parties are ok with 
>> the request happening, the requesting site and the target site. But 
>> the user is not asked. The solution I've always had in mind for this 
>> is that the target site is responsible for asking the user that 
>> handing out his/her data is ok before doing so. However it's very 
>> possible that they will not.
>>
>>
>> Possible solution:
>> One possible solution that was discussed was that the browser could 
>> at the time of the request ask the user something like "linkedin.com 
>> is trying to read some of your personal data from yahoo.com, is this 
>> ok?". There are several issues with this though. In general asking 
>> the user security questions is a bad idea since many people don't 
>> understand the issue.
>>
>> Also, implementation wise it's tricky since the load will have to be 
>> stalled until the user answers. This more or less require in-you-face 
>> UI, such as a dialog which we're always trying to avoid.
>>
>> Additionally, doing this pretty drastically changes the semantics of 
>> the Access-Control spec. For now we have said that just because a 
>> request is coming from the user doesn't mean that the user has 
>> approved it.
I think that a world of pop-up security questions is not viable (in the 
sense that users will either click Yes to everything or flock to UAs 
that aren't so annoying).  Having an option of either federated 
site-to-site trust relationships or user-centric site opt-in is, I 
think, viable.  But this requires mechanisms outside the scope of AC.
>>
>>
>> For now mozilla has decided *not* to send cookies, though we are very
>> interested in hearing your feedback.
I think I'm happy with this as it would force sites to adopt more secure 
authorization mechanisms.

John
Disclosure: I work at Google but these are just my own ramblings.

Received on Friday, 22 February 2008 17:07:58 UTC