Re: Opting in to cookies - proposal

On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote:
>
>
>> I must say though, this is starting to sound complex and I am not  
>> totally convinced of the need to make servers opt in to getting  
>> cookies. Is it really a likely mistake that someone would take  
>> affirmative steps to enable cross-site access to a per-user  
>> resource, but then neglect to check whether requests are cross-site  
>> and act appropriately?
>
> I do think there is a big risk of that yes. I do think that many  
> sites that today serve public data do have a few pages in there  
> which contain forms or other pages that serve user specific data.
>
> Even something as simple as a news site that largely serves public  
> news articles might have a cookie where the user has chosen a home  
> location for local news. This is the case on the news site I use for  
> example, it usually just serves a standard list of news, but if I  
> give it my home zip code, it will additionally serve a section of  
> local news.

I guess I don't see that as a huge risk. In the case of the  
hypothetical news site, if it is handing out news in some kind of data  
feed format, wouldn't the point of access-control be to give the  
personalized feed? After all, you could otherwise use server-to-server  
communication to get the public data.

>
> This is something that could very easily be overlooked by an  
> administrator that just configures his server to add a "Access- 
> Control: allow<*>" header using a site-wide configuration file,  
> without going through all CGI scripts on the server and teaching the  
> ones that honor cookies to ignore the cookies for cross-site requests.

No site should add "Access-Control: allow<*>" site-wide! I mean, I  
guess it's possible people will do this, but people could add "Access- 
Control-Allow-Credentials" site-wide too. And if we add "Access- 
Control-Allow-Credentials-I-Really-Mean-It", they'll add even more.

Basically the part of this that worries me is that it requires  
agreement between the client and the server, but those are expected to  
be controlled by different parties in many cases. If our favorite news  
site starts out only offering unpersonalized news feeds to other  
sites, but then wants to use cookies to personalize, then all existing  
clients of its cross-site data must change. That seems like a huge  
burden. Worse yet, if the site changes its mind in the other  
direction, existing clients break completely.

>
>> And if the administrator of such a server thoughtlessly enabled  
>> cross-site access without thinking about the consequences, would  
>> they not be equally likely to enable cross-site cookies without  
>> thinking about the consequences?
>
> Not more likely than someone adding any other header without knowing  
> what it does. This is why I designed my proposal such that opting in  
> to cookies is a separate "step".

But you are expecting people to add Access-Control without knowing  
what it does.

>> It seems like we are adding a lot of complexity (and therefore more  
>> opportunity for implementation mistakes) for a marginal reduction  
>> in the likelihood of server configuration errors.
>
> I think the ability to separate sharing of private data from sharing  
> of public data is a huge help for server operators. So I think this  
> is much more than a marginal reduction of configuration errors.

The possibility of making this separation is there - simply ignore  
Cookie and/or Authorization headers when Access-Control-Origin is  
present. So this opt-in doesn't offer a new capability, just changes  
the defaults.

After reviewing your comments, I am much more inclined to favor  
Microsoft's proposal on this: rename the relevant headers. I think you  
argued that this "doesn't scale", but I think only two headers have to  
be renamed, "Cookie" and "Authorization". Note that other  
authentication-related headers, if any, do not need to be renamed,  
because without the "Authorization" header being present, no other  
authentication processing will take place. If the headers have  
different names, it's very hard to reveal private data accidentally.  
No site-wide blanket addition with headers will cause it, you have to  
go out of your way to process an extra header and treat it the same as  
"Cookie". It would allow allow servers to choose whether to offer  
personalized or public data and change their mind at any time, without  
having to change clients of the data. It would also work for inclusion  
of cross-site data via mechanisms that don't have a convenient way to  
add an out of band flag.

The only downside I can think of to this approach is that it may break  
load balancers that look at cookies, unless they are changed to also  
consider the new header ("Cross-Site-Cookie"?).

> I asked this in a separate thread already, but have you guys at  
> apple had your security people look through the spec. Were they  
> comfortable both with always sending cookies as well as always  
> enabling all HTTP methods and headers?

I am one of Apple's security people, at least with respect to browser  
stuff. We do our best to coordinate with other security experts at the  
company as well.

Regards,
Maciej

Received on Thursday, 19 June 2008 15:39:15 UTC