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