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.
