To cookie or not to cookie

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.


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.

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.


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).

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.


So to sum up:
The risk when sending cookies is that sites that opt in to
access-control don't realize what they are opting in to. I.e. don't
realize that just because the request is coming from the user, that the
user has authorized it.

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. Putting 
up a dialog like that would seem to indicate that the user *has* indeed 
requested the


For now mozilla has decided *not* to send cookies, though we are very
interested in hearing your feedback.

Best Regards,
Jonas Sicking

Received on Friday, 22 February 2008 07:30:39 UTC