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
