Re: To cookie or not to cookie

On cookies and CSRs:

I sounds like we are close to agreeing that sending cookies w/ CSRs is
not a server attack issue, but a client privacy issue - a possible
'data leak.' I think this is right. To that end, I think the focus
should be on how to properly put users in control of their private
data.

I suggest we leverage existing browser UI models to help users decide
what to do. All browsers have a whitelist/blacklist model to control
which sites can use cookies. The MSIE browser has 'security zones' to
allow users to control what features sites (or site groups)  are
allowed to offer. Browsers allow users to prompt them when moving from
HTTPS to HTTP. Ad-block plugins addres the issue of cross-site cookies
directly by allowing users to white/black-list sites.

These are all examples of browsers allowing users to control their privacy.

MikeA

On Fri, Feb 22, 2008 at 2:38 AM, Jonas Sicking <jonas@sicking.cc> 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.
>  >
>  >
>  > 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
>  >
>
>
>



-- 
mca
http://amundsen.com/blog/

Received on Saturday, 23 February 2008 16:11:12 UTC