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 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 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 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
