Re: Opting in to cookies - proposal
* Jonas Sicking wrote: I'm not quite following what you are asking here. My proposal is about giving a site the ability to enable two modes of Access-Control: 1. Allow a third-party site to read the data on this resource, and/or perform unsafe methods in HTTP requests to this resource. When these requests are sent any cookie and/or auth headers (for the resource) are included in the request, just as if had been a same-site XHR request. 2. Same as above, but requests never include cookies or auth headers are never included. In the spec currently only mode 1 is possible. I suggest that we make mode 2 possible as well. I guess you can call it opting out of cookies as well... I am proposing that there be only a single mode unless it can clearly be demonstrated that having two modes would be a substantial net gain. As far as I am aware, this has not been established for a with-cookie mode if the no-cookie mode is the default, and my questions focus on learning more about the with-cookie mode. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Opting in to cookies - proposal
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: I'm not quite following what you are asking here. My proposal is about giving a site the ability to enable two modes of Access-Control: 1. Allow a third-party site to read the data on this resource, and/or perform unsafe methods in HTTP requests to this resource. When these requests are sent any cookie and/or auth headers (for the resource) are included in the request, just as if had been a same-site XHR request. 2. Same as above, but requests never include cookies or auth headers are never included. In the spec currently only mode 1 is possible. I suggest that we make mode 2 possible as well. I guess you can call it opting out of cookies as well... I am proposing that there be only a single mode unless it can clearly be demonstrated that having two modes would be a substantial net gain. As far as I am aware, this has not been established for a with-cookie mode if the no-cookie mode is the default, and my questions focus on learning more about the with-cookie mode. Not sure if there is much of a 'default' mode no matter what, since it's the website that chooses if it wants to receive cookies or not. But anyway... Allowing with cookies has obvious benefits. It allows the target size to know which user data is requested for. So if the requesting site is trusted by the target site, the target site can send user-private data (note, this trust has to be established out-of-band from the spec, usually by the target site asking the user) and know which users data to send. Additionally, this is done without needing to entrust the requesting site with any user credentials. It also neatly integrates with security solutions inside ASP, PHP, etc without having to deploy a new infrastructure to handle these things. Allowing without cookies gives websites that want to publish public data a tool to significantly safer opt in to Access-Control without having to worry about accidentally leaking users private data. Accidentally leaking private data can happen in two instances that I can think of: * The operator opts in to AC on a subsection of the site forgetting that somewhere deeply nested is a form with CRSF protection which isn't supposed to be readable cross-site. Or there is a resource that serves user-private data which isn't supposed to be readable cross-site. * The operator opts in to AC on a URI that mostly serves public data, but forgets that if the user is logged in the URI also serves some user-private data. I do admit that I do not yet know how likely it is that operators will make any of the mistakes listed above, so I can't give an exact cost/benefit analysis. / Jonas
Re: Opting in to cookies - proposal
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: First off, as before, when I talk about cookies in this mail I really mean cookies + digest auth headers + any other headers that carry the users credentials to a site. I don't quite see why you would mix these. Is there anywhere where I can read up on the use cases for an extra feature to enable the transmission of cookies if not included by default? Especially for users credentials in cookies it is difficult to imagine real world applications that would depend on or at least greatly benefit from such a feature. I'm not quite following what you are asking here. My proposal is about giving a site the ability to enable two modes of Access-Control: 1. Allow a third-party site to read the data on this resource, and/or perform unsafe methods in HTTP requests to this resource. When these requests are sent any cookie and/or auth headers (for the resource) are included in the request, just as if had been a same-site XHR request. 2. Same as above, but requests never include cookies or auth headers are never included. In the spec currently only mode 1 is possible. I suggest that we make mode 2 possible as well. I guess you can call it opting out of cookies as well... / Jonas
Re: Opting in to cookies - proposal
* Jonas Sicking wrote: First off, as before, when I talk about cookies in this mail I really mean cookies + digest auth headers + any other headers that carry the users credentials to a site. I don't quite see why you would mix these. Is there anywhere where I can read up on the use cases for an extra feature to enable the transmission of cookies if not included by default? Especially for users credentials in cookies it is difficult to imagine real world applications that would depend on or at least greatly benefit from such a feature. By use case I mean elaborate descriptions of how a user would use the system as a whole to accomplish some well-defined and meaningful goal. I am particularily interested in the user interface research relative to this, for example, how the user is involved in the decision whether the cookies are sent, and when they should be sent but are not (because the user is not logged in at all with the other application, or the session has expired). It would seem that one way or the other, the embedding site would have to ask the user to login into the embedded site and stay logged in while it attempts to do whatever it is supposed to do. Training users to do that would of course lead to social engineering attacks (Please make sure you are logged into your account iframe/, then exploit some vul- nerability on the site, say a session riding one unrelated to AC). So I am wondering what I am missing here. Similarily, if this is just for some value-added services, it would be very interesting to see the usability research on how users react when, say, their customizations on some site suddenly no longer leak into the embedding application (which of course depends on whether, say, they had to consent before the browser would send the cookies to the embedded site, in that case they would have at least a clue where the error may come from). So in general I am rather doubtful that an option to send cookies along, be that with the Cookie or some alternate cookie header, is the best way to address whatever problem is supposed to be solved by this (not that I have seen a list, sufficiently detailed to propose alternate solutions, of those so far; if they are available I'd appreciate a pointer). By the time implementations of this are widely available, developers will have alternate technologies at their disposal to implement whatever cookie- dependant services they want. So since the idea here is to keep the attack surface managable, it seems the best course of action would be to not add this feature in the first place, unless and until we have detailed information on why applications cannot do without it sent here to the list and subjected it to public scrutiny. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Thu, 19 Jun 2008, Jonas Sicking wrote: That is, your solution only works so long as the site doesn't ever opt in to cookies. Which seems uncommon. This is not true. You can opt in to cookies on just a subset of the URIs where you opt in to Access-Control with my proposal. But the _entire assumption_ here is that the author is unable to correctly apply these features to the right subset of his site. If the author was able to correctly apply these features to the appropriate subset, then we wouldn't need your feature in the first place. No, that is not the assumption. I'll try to rephrase. In the example below i'll use PHP as the server side technology for: My concern is for a site operator which understands the spec and wants to share public data being offered from all or part of the URI space for the site. Under the current spec the operator must check each individual PHP script in the part of the site that is shared to make sure that none of them use $_SESSION, $_COOKIE, $HTTP_SESSION_VARS, $_ENV['HTTP_COOKIE'], HttpRequest::getCookies(), any of the session_* functions, $_ENV['REMOTE_USER'], $_ENV['REMOTE_IDENT'], $_ENV['HTTP_AUTHORIZATION'] any of the kadm5_* functions, any of the radius_* functions or anything else that I'm missing that does session management based on user credentials. If any of these things are used then the PHP script is likely mixing private data into the public data and so the script needs to be modified to not use any of the above features when the 'Origin' header is present and has a value different from the current domain. While this is certainly doable, I feel that there is a risk that the site administrator will make a mistake and miss some of the above listed features and cause private data to be leaked. So again, the issue isn't in understanding the spec. The issue is securing your site for the security model that the spec requires. Additionally, this way you can make sure to ask the user always before sending the Access-Control-With-Credentials header. This way the risk of leaking private data without the user realizing is further reduced. But we both know browsers aren't going to do this, or will offer a never ask me again checkbox. I'm talking about the site asking the user this question. The site should always check with the user before sharing any of the users private data with any third party. If we separate out opting in to cookies from opting in to Access-Control then sites can easier ensure that any time they opt in to cookies, they only do so after having asked the user. (I'm assuming that the case of providing data cross-domain for simple GET requests is most easily handled just by having that script send back the right magic, in which case none of this applies as the URI space is one URI and there are no preflights at all. For this use case we don't have to worry about cookies at all as the server just wouldn't look at them.) I'm not following what you are saying here. What script is that script? And what is the right magic? The script that provides the data, and the right magic is the Access-Control header. I'm sorry, i'm totally at a loss about what you are saying here, I suspect I'm missing some context. Could explain from the beginning? / Jonas
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Fri, 20 Jun 2008, Jonas Sicking wrote: Under the current spec the operator must check each individual PHP script in the part of the site that is shared to make sure that none of them use $_SESSION, $_COOKIE, $HTTP_SESSION_VARS, $_ENV['HTTP_COOKIE'], HttpRequest::getCookies(), any of the session_* functions, $_ENV['REMOTE_USER'], $_ENV['REMOTE_IDENT'], $_ENV['HTTP_AUTHORIZATION'] any of the kadm5_* functions, any of the radius_* functions or anything else that I'm missing that does session management based on user credentials. If any of these things are used then the PHP script is likely mixing private data into the public data and so the script needs to be modified to not use any of the above features when the 'Origin' header is present and has a value different from the current domain. While this is certainly doable, I feel that there is a risk that the site administrator will make a mistake and miss some of the above listed features and cause private data to be leaked. So again, the issue isn't in understanding the spec. The issue is securing your site for the security model that the spec requires. That's all well and good, but what if the site author wants to send back some data that _is_ cookie aware? Now he has to go through and do the check anyway. So what's the win? I think it's safe to assume that if the site uses cookies at all, that it'll eventually want to provide cross-site access to user data in some way. Ah, sorry, I think I missed your point here. I don't think that is unnecessarily true at all. I think one sticking point is that I suspect sites will opt in to Access-Control on pages they are already serving to their users. So I would not be surprised if yahoo opts in on the uri news.yahoo.com URI, or craigslist opt in for their full URI space. In such cases I think it's very possible that sites will opt in on URIs that receive and process cookies, but would leak private data if they did so with cookies enabled. / Jonas
Re: Opting in to cookies - proposal version 3
On Thu, 19 Jun 2008 11:42:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 19 Jun 2008, Jonas Sicking wrote: This has one side-effect, which is that it doesn't work well with XBL or VBWG in environments where the XBL file (or VXML file) is customised to the user but accessed cross-site. Is that ok? It doesn't work well in the sense that they don't work out-of-the-box. It would be trivial to add a load-private-data pseudo attribute to the ?xbl? PI that sets the with credentials flag to true. However I can't think of a situation where someone wants to load private XBL bindings so I'm totally ok with it being a bit more hassle. It might be a bigger deal for VXML, I don't know since I've not looked at that spec. Sounds fair to me. I'll add the attribute to XBL2 when it goes back to LC once implementations start, assuming we adopt this. Ian, it seemed to me you were talking about the server side problem because ?access-control? alone would not be enough. XBL being served would need to be served with the appropriate HTTP headers set. (Also, not just ?xbl? would need to be changed but also the other APIs for attaching XBL would require changing I presume.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Opting in to cookies - proposal
Maciej Stachowiak wrote: 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? If the site gives out a personalized feed it has to be *a lot* more careful who it gives it out to. It must first ask the user for every site it gives the feed to. If it just gives out non-personalized feeds it can safely share the feed with any site. After all, you could otherwise use server-to-server communication to get the public data. Yes, but server-to-server communication has a lot of downsides. First of all it greatly increases the latency since the information is transferred over two connections rather than one. Second, it means that you have to have a server that has enough capacity to tunnel all the mashup data for all the users of your site. This can be a significant hurdle. 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! Experiences with Adobes crossdomain.xml show that they do. 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. Yes, this is certainly a possibility. But my hope is that this will happen to a smaller extent. 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. If you start sharing a new set of data it makes a lot of sense to me that people reading that data need to change. This seems no different than if you change from sharing an address book to sharing emails. Usually someone reading the data would need to both change the URI they are reading, as well as how they display the data. 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's not a matter of knowing what the spec says, its a matter of knowing with 100% certainty that you are not sending any private data on any of the URIs you are sharing. 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. In many server technologies it's not trivial to ignore cookies and/or auth headers. Session handling tends to be handled before the CGI script starts which means that you have to weed
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Thu, 19 Jun 2008, Jonas Sicking wrote: And it's useful for pages that contain private information only when cookies are sent, but when no cookies are sent they only provide public information. I've given two examples of this in other threads: 1. A news site serving articles in different categories. When the user is logged in and has configured a home zipcode includes a category of local news. Example: news.yahoo.com 2. A discussion board that allows comments to be marked private. Only when a user is logged in and has access to private comments are the private comments included, otherwise only the public comments are shown. Example: buzilla.mozilla.com For these, how would the site initating the connection to the data provider server know whether or not to include the load-private-data flag? The same way that it knows which URI to load. I expect that sites will document what resources can be loaded at what URIs, and with which query parameters as part of the API documentation. Whether private data is served can be documented at the same place. Along with information on what to do if access is denied for that private information. Surely if the server does anything with the load-private-data flag, then it is fundamentally as vulnerable as if we didn't do any of this. Yes, this is about reducing likelyhood that things go wrong, not eliminating it as that seems impossible. This only helps with servers that have same-domain pages that accept cookies, but have no cross-domain pages that accept cookies, ever (since if any of the cross-domain pages accept cookies, then our initial assumption -- that the site author makes a mistake and his site reacts to cookies in third-party requests by doing bad things -- means that he's lost). How so. Sites that have a combination of private and public data can, and hopefully will, only set the Access-Control-With-Credentials header for the parts that serve private data. It needs to apply different opt-in policies here anyway since it needs to ask the user before sharing any of his/her data. / Jonas
Re: Opting in to cookies - proposal
Maciej Stachowiak wrote: On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote: ...snip... 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. Yes, this is certainly a possibility. But my hope is that this will happen to a smaller extent. I share the hope smaller extent hope with Jonas, and his latest proposals look good to me. My assumption is that 99% of all cross-site XHR usage will not require credentials/cookies. Therefore, what makes sense is a simple way that server developers can opt-in to credential-free cross-site XHR which tells the browser to allow cross-site credential-free XHR to their site. Then, in an advanced section of the AC spec, talk about how some workflows might want credentials to be sent, and here is the extra header to enable credentials (Access-Control-Allow-Credentials), but this section of the spec should include SHOUTING TEXT about potential dangers and instruct the developer that he should not enable transmission of credentials unless he is sure that he needs it and he is sure that he knows what he is doing (such as understanding what a CSRF attack is). I realize that some developers won't read the spec carefully or notice the shouting text, but I expect most tutorials and examples on the Web will follow the lead from the spec and help to teach people steer clear of the Access-Control-Allow-Credentials header unless they know what they are doing. Jon
Re: Opting in to cookies - proposal version 3
On Thu, 19 Jun 2008, Jonas Sicking wrote: This only helps with servers that have same-domain pages that accept cookies, but have no cross-domain pages that accept cookies, ever (since if any of the cross-domain pages accept cookies, then our initial assumption -- that the site author makes a mistake and his site reacts to cookies in third-party requests by doing bad things -- means that he's lost). How so. Sites that have a combination of private and public data can, and hopefully will, only set the Access-Control-With-Credentials header for the parts that serve private data. It needs to apply different opt-in policies here anyway since it needs to ask the user before sharing any of his/her data. The scenario we are trying to address is the scenario where an author has accidentally allowed cross-site access to a part of the site that gives users abilities if they provide valid credentials, to prevent other sites from pretending to be the user and acting in a user-hostile way as if on the user's behalf. Thus we are assuming that if a cookie is sent to the server with a cross-site request, the server will be vulnerable. That is the fundamental assumption. Now, we can work around that by making it that authors don't accept cookies for cross-site requests, but only accept them from same-site requests. That works, because our assumption only relates to cross-site requests that _do_ include cookies. If the server then opts-in to receiving cookies, then the server will receive cookies. Our assumption is that if a cookie is sent to the server with a cross-site request, the server will be vulnerable. Thus the server is now again vulnerable. We can't pretend that the author will make a mistake if they always receive cookies but then assume that the author will suddenly stop making mistakes when we provide them with a way to opt-in to cookies. Either the author is going to make mistakes, or he isn't. We have to be consistent in our threat assessment. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Opting in to cookies - proposal
On Jun 19, 2008, at 1:48 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: 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?). Using different header names would certainly address the concern I have regarding reducing the risk that private data is inadvertently leaked. However I think the downsides are pretty big. The load balancer issue you bring up is just one example. Another is that I think caching proxies today avoid caching data that is requested using Authentication headers. Probably the same is true for the cookie header in some configurations. I think going against the HTTP spec carries big unknown risks. I'm sure others with more HTTP experience than me can chime in here better. I don't see how this would go against HTTP. It's perfectly valid HTTP to not send Cookie or Authorization headers, and also valid to send whatever custom headers you want if agreed upon with the server. The cost and risk of adding an extra boolean to XMLHttpRequest seems much lower. The cost of tying server-side changes to client-side changes for a cross-site communication technology seems like a very high cost to me. I don't buy the argument that it's normal to change when you change what data you are reading - the data being personalized (or not) is a different kind of change from changing the type of data you read. To compare to the user-level example, GMail and GCal are different URLs, but nytimes.com is the same URL whether I'm logged in or not. Regards, Maciej
Re: Opting in to cookies - proposal
Maciej Stachowiak wrote: On Jun 19, 2008, at 1:48 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: 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?). Using different header names would certainly address the concern I have regarding reducing the risk that private data is inadvertently leaked. However I think the downsides are pretty big. The load balancer issue you bring up is just one example. Another is that I think caching proxies today avoid caching data that is requested using Authentication headers. Probably the same is true for the cookie header in some configurations. I think going against the HTTP spec carries big unknown risks. I'm sure others with more HTTP experience than me can chime in here better. I don't see how this would go against HTTP. It's perfectly valid HTTP to not send Cookie or Authorization headers, and also valid to send whatever custom headers you want if agreed upon with the server. You are sending data that the HTTP spec specifies should be sent over an Authorization header over another header instead. In any case, if you are breaking the letter and/or spirit of the spec is of little matter. What matters is the actual effects are of sending this information over new header names are. The cost and risk of adding an extra boolean to XMLHttpRequest seems much lower. The cost of tying server-side changes to client-side changes for a cross-site communication technology seems like a very high cost to me. I don't buy the argument that it's normal to change when you change what data you are reading - the data being personalized (or not) is a different kind of change from changing the type of data you read. To compare to the user-level example, GMail and GCal are different URLs, but nytimes.com is the same URL whether I'm logged in or not. First of all I'm unconvinced that this will happen in reality. Can you explain a usecase when a site would want to go from changing from public data to private data, without changing anything else? And is this common enough that we need to cater to it? When you are sending personalized data you pretty much have to have a pretty different API anyway. At the very least the mashup sites will have to deal with access being denied and display some UI to the user, or redirect the user to the content site to log in and/or authorize the mashup site to read the data. I would think that in most cases you would keep the old URI serving the public data, and set up a new URI where you can fetch the private data. It might be a small change implementation wise, but semantically and security wise it's a big difference between serving public and private data. / Jonas
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Thu, 19 Jun 2008, Jonas Sicking wrote: This only helps with servers that have same-domain pages that accept cookies, but have no cross-domain pages that accept cookies, ever (since if any of the cross-domain pages accept cookies, then our initial assumption -- that the site author makes a mistake and his site reacts to cookies in third-party requests by doing bad things -- means that he's lost). How so. Sites that have a combination of private and public data can, and hopefully will, only set the Access-Control-With-Credentials header for the parts that serve private data. It needs to apply different opt-in policies here anyway since it needs to ask the user before sharing any of his/her data. The scenario we are trying to address is the scenario where an author has accidentally allowed cross-site access to a part of the site that gives users abilities if they provide valid credentials, to prevent other sites from pretending to be the user and acting in a user-hostile way as if on the user's behalf. Thus we are assuming that if a cookie is sent to the server with a cross-site request, the server will be vulnerable. That is the fundamental assumption. Now, we can work around that by making it that authors don't accept cookies for cross-site requests, but only accept them from same-site requests. That works, because our assumption only relates to cross-site requests that _do_ include cookies. If the server then opts-in to receiving cookies, then the server will receive cookies. Our assumption is that if a cookie is sent to the server with a cross-site request, the server will be vulnerable. Thus the server is now again vulnerable. We can't pretend that the author will make a mistake if they always receive cookies but then assume that the author will suddenly stop making mistakes when we provide them with a way to opt-in to cookies. Either the author is going to make mistakes, or he isn't. We have to be consistent in our threat assessment. Yes, if they only do that then they will be vulnerable. The site is as always responsible for asking the user before allowing third-party access to private data, and yes, if they fail to do so properly they will be vulnerable. / Jonas
Re: Opting in to cookies - proposal version 3
On Thu, 19 Jun 2008, Jonas Sicking wrote: The site is as always responsible for asking the user before allowing third-party access to private data, and yes, if they fail to do so properly they will be vulnerable. So I guess I don't really understand what your proposal solves, then. It seems like a lot of complexity for only a very minimal gain in only one very specific scenario (the site doesn't ever return cookie-based data cross-site). We're still relying on the author not making mistakes, despite the author will make a mistake being our underlying assumption. If the site has to know to not include the cookie opt-in header, why not just have the site ignore the cookies? (It also introduces the problems that Maciej mentioned, which I think are valid problems.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Thu, 19 Jun 2008, Jonas Sicking wrote: The site is as always responsible for asking the user before allowing third-party access to private data, and yes, if they fail to do so properly they will be vulnerable. So I guess I don't really understand what your proposal solves, then. It seems like a lot of complexity for only a very minimal gain in only one very specific scenario (the site doesn't ever return cookie-based data cross-site). We're still relying on the author not making mistakes, despite the author will make a mistake being our underlying assumption. If the site has to know to not include the cookie opt-in header, why not just have the site ignore the cookies? (It also introduces the problems that Maciej mentioned, which I think are valid problems.) Well, we are talking about two very different types of misstakes, which I think have very different likelyhoods of happening. If I understand you correctly. One misstake is having URIs in the URI space where you opt in to Access-Control which serve private data without you realizing it. The other mistake is intentionally publishing private data but forgetting to ask your users first before doing so. Seems to me that the former is a lot more likely than the latter. / Jonas Btw, I just realized that this thread says version 3, not sure why I made that mistake, this is obviously version 2 :)
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Thu, 19 Jun 2008, Jonas Sicking wrote: So I guess I don't really understand what your proposal solves, then. It seems like a lot of complexity for only a very minimal gain in only one very specific scenario (the site doesn't ever return cookie-based data cross-site). We're still relying on the author not making mistakes, despite the author will make a mistake being our underlying assumption. If the site has to know to not include the cookie opt-in header, why not just have the site ignore the cookies? (It also introduces the problems that Maciej mentioned, which I think are valid problems.) Well, we are talking about two very different types of misstakes, which I think have very different likelyhoods of happening. If I understand you correctly. One misstake is having URIs in the URI space where you opt in to Access-Control which serve private data without you realizing it. The other mistake is intentionally publishing private data but forgetting to ask your users first before doing so. Seems to me that the former is a lot more likely than the latter. Right but the mistake that we're not doing anything about and which seems likely to be far more common than either of those is: Having URIs in the URI space where you opt in to Access-Control _and_ opt in to cookies which serve or affect private data without you realizing it. Yes, the best way I can think of to reduce this risk is to reduce the number of URIs where you opt in to cookies. That is what my proposal tries to accomplish. That is, your solution only works so long as the site doesn't ever opt in to cookies. Which seems uncommon. This is not true. You can opt in to cookies on just a subset of the URIs where you opt in to Access-Control with my proposal. Additionally, this way you can make sure to ask the user always before sending the Access-Control-With-Credentials header. This way the risk of leaking private data without the user realizing is further reduced. If cookies are always turned on for Access-Control there will be many situations where you will want to enable Access-Control without asking a user since you are not sending the users private data. (I'm assuming that the case of providing data cross-domain for simple GET requests is most easily handled just by having that script send back the right magic, in which case none of this applies as the URI space is one URI and there are no preflights at all. For this use case we don't have to worry about cookies at all as the server just wouldn't look at them.) I'm not following what you are saying here. What script is that script? And what is the right magic? I am just as concerned about GET requests as any other. In fact, all the private data leaks I've heard about with crossdomain.xml has been related to GET requests. / Jonas
Re: Opting in to cookies - proposal
On Sat, 14 Jun 2008 10:38:44 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: The downsides of inventing a URI scheme include: 1) URIs using this scheme will not parse into components properly (the feed: scheme has this problem) 2) The scheme really should be registered through IANA, which will be a bureaucratic hassle 3) IANA would probably be hesitant, because user-private: does not describe a new resource access method, it just describes what headers you want to send, which in http is separate from the URI 4) It is in fact a valid point that this violates the design of URI schemes 5) Code throughout the system will have to know to special-case this URI scheme to treat it as equivalent to the corresponding HTTP URI I strongly agree that if we do this at all we should not do it through a new URI scheme. If we do this something like Hixie's original proposal makes more sense to me (and maybe allowing it to be influenced by a flag): http://lists.w3.org/Archives/Public/public-appformats/2008May/0007.html -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
