Re: To cookie or not to cookie

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
>

Received on Friday, 22 February 2008 07:38:27 UTC