Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Fri, 08 Aug 2008 20:44:04 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The big worry I have though is if there is any possibility to puny encode the same origin in multiple ways (other than with or without default port). This could lead to different UAs encoding the same origin in different ways, which could lead to interoperability issues if sites rather than echoing the 'Origin' header always send out a static value for the Access-Control-Allow-Origin header. Is that possible? I don't think it is. Domain names follow a strict set of normalization rules. (That would also mean the Origin header could contain different values depending on the implementation, which is not the case.) The only thing that i _know_ of is that: http://foo.com and http://foo.com:80 are the same origin but have different string representations. I have also heard that some UAs are able to handle non-ascii characters in header values by somehow specifying an encoding. I don't really know how that works, but for those UAs the following to origins would be equivalent: http://www.xn--jrnspikar-v2a.com and http://www.järnspikar.com / Jonas
Re: XDomainRequest Integration with AC
On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The only thing that i _know_ of is that: http://foo.com and http://foo.com:80 are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them as well.) I have also heard that some UAs are able to handle non-ascii characters in header values by somehow specifying an encoding. I don't really know how that works, but for those UAs the following to origins would be equivalent: http://www.xn--jrnspikar-v2a.com and http://www.järnspikar.com Using the latter is non-conforming for Origin and also non-conforming for Access-Control-Allow-Origin, which per its current definition either mathces Origin literally or is a wildcard. So currently RFC 2047 extensions are simply not supported (and not needeD) by the specification. Given that interoperability on encoded-word is very poor I suggest we keep it that way. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: ... Using the latter is non-conforming for Origin and also non-conforming for Access-Control-Allow-Origin, which per its current definition either mathces Origin literally or is a wildcard. So currently RFC 2047 extensions are simply not supported (and not needeD) by the specification. Given that interoperability on encoded-word is very poor I suggest we keep it that way. ... By all means, please do so. Maybe add a warning that RFC 2047 encoding is *not* allowed? BR, Julian
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: http://foo.com and http://foo.com:80 are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them as well.) I might be missing some context here... but use the former where, exactly? Would a page loaded from the latter not be able to do AC stuff? In general, I think forcing authors to think about whether the port is included is really poor practice and sounds like it would break real-world systems (e.g. any system that wants to run HTTP servers on multiple ports and just always specifies ports everywhere instead of specifying 8080 but not 80). Handling this in UAs is almost certainly reasonably straightforward (have to replace string compares with origin object compares, with the objects doing port normalization as needed). It doesn't seem like it would be hard to deal with in the spec either, though obviously it's a bit more work than just not dealing. So I'm not sure why we want to break the long-standing (and imo obvious per the relevant RFCs) convention that you get the same behavior for http:// no matter whether the port is explicitly listed as 80. -Boris
Re: XDomainRequest Integration with AC
On Fri, 05 Sep 2008 14:42:45 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: http://foo.com and http://foo.com:80 are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them as well.) I might be missing some context here... but use the former where, exactly? In the Access-Control-Allow-Origin header. Would a page loaded from the latter not be able to do AC stuff? That wouldn't matter. In general, I think forcing authors to think about whether the port is included is really poor practice and sounds like it would break real-world systems (e.g. any system that wants to run HTTP servers on multiple ports and just always specifies ports everywhere instead of specifying 8080 but not 80). Handling this in UAs is almost certainly reasonably straightforward (have to replace string compares with origin object compares, with the objects doing port normalization as needed). It doesn't seem like it would be hard to deal with in the spec either, though obviously it's a bit more work than just not dealing. So I'm not sure why we want to break the long-standing (and imo obvious per the relevant RFCs) convention that you get the same behavior for http:// no matter whether the port is explicitly listed as 80. That sounds reasonable. What's currently specified is equivalent to what HTML 5 specifies for the WebSocket protocol. It seemed reasonable to keep the two synchronized somewhat though maybe they should both change. Though do note that the value authors get (through the Origin header) will be without the default port so authors will have to deal with this anyway. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XDomainRequest Integration with AC
On Fri, 08 Aug 2008 20:44:04 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The big worry I have though is if there is any possibility to puny encode the same origin in multiple ways (other than with or without default port). This could lead to different UAs encoding the same origin in different ways, which could lead to interoperability issues if sites rather than echoing the 'Origin' header always send out a static value for the Access-Control-Allow-Origin header. Is that possible? I don't think it is. Domain names follow a strict set of normalization rules. (That would also mean the Origin header could contain different values depending on the implementation, which is not the case.) In general, I don't think it's a lot of work to require a strict same-origin check. All browsers should have such an algorithm implemented anyway. True, but if we can make things simpler that seems better. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Wed, 30 Jul 2008 18:19:20 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, [host, and port]. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. I think all of these should be disallowed. My plan is to simply require Access-Control-Allow-Origin to hold the ASCII serialization of an origin (see HTML5) and have a literal comparison of that with the value of Origin. This would be quite strict, but should be fine I think. That is fine, though I'm inclined to think that the trailing slash should be allowed in the HTML5 syntax for an origin. / Jonas
Re: XDomainRequest Integration with AC
Anne van Kesteren wrote: On Fri, 08 Aug 2008 08:28:48 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: My plan is to simply require Access-Control-Allow-Origin to hold the ASCII serialization of an origin (see HTML5) and have a literal comparison of that with the value of Origin. This would be quite strict, but should be fine I think. That is fine, though I'm inclined to think that the trailing slash should be allowed in the HTML5 syntax for an origin. That would would preclude string comparison though and require something less trivial. How would that preclude string comparison? (- http://greenbytes.de/tech/webdav/rfc3986.html#comparison-string) BR, Julian
Re: XDomainRequest Integration with AC
On Fri, 08 Aug 2008 11:20:44 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Fri, 08 Aug 2008 08:28:48 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: My plan is to simply require Access-Control-Allow-Origin to hold the ASCII serialization of an origin (see HTML5) and have a literal comparison of that with the value of Origin. This would be quite strict, but should be fine I think. That is fine, though I'm inclined to think that the trailing slash should be allowed in the HTML5 syntax for an origin. That would would preclude string comparison though and require something less trivial. How would that preclude string comparison? (- http://greenbytes.de/tech/webdav/rfc3986.html#comparison-string) If it is merely allowed and not always there you can't perform string comparison but instead have to strip the trailing slash first or something like that, etc. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XDomainRequest Integration with AC
On Fri, 08 Aug 2008 11:38:55 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: String comparison is not going to be ok either way. The following two origins are equivalent: http://www.foo.com http://www.foo.com:80 My proposal was to treat those as non-equivalent. Basically, to require Access-Control-Allow-Origin to have the same value as Origin. (It seems that Ian has used this approach for WebSocket as well.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XDomainRequest Integration with AC
Jonas Sicking wrote: Anne van Kesteren wrote: On Fri, 08 Aug 2008 11:38:55 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: String comparison is not going to be ok either way. The following two origins are equivalent: http://www.foo.com http://www.foo.com:80 My proposal was to treat those as non-equivalent. Basically, to require Access-Control-Allow-Origin to have the same value as Origin. The downside with doing that is that we can't use the same syntax for Access-Control as for postMessage. (Yes, I'm still intending to get postMessage fixed, haven't had time yet though). Not sure how big the value is in that though... The big worry I have though is if there is any possibility to puny encode the same origin in multiple ways (other than with or without default port). This could lead to different UAs encoding the same origin in different ways, which could lead to interoperability issues if sites rather than echoing the 'Origin' header always send out a static value for the Access-Control-Allow-Origin header. In general, I don't think it's a lot of work to require a strict same-origin check. All browsers should have such an algorithm implemented anyway. / Jonas
Re: XDomainRequest Integration with AC
On Wed, 30 Jul 2008 18:19:20 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, [host, and port]. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. I think all of these should be disallowed. My plan is to simply require Access-Control-Allow-Origin to hold the ASCII serialization of an origin (see HTML5) and have a literal comparison of that with the value of Origin. This would be quite strict, but should be fine I think. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XDomainRequest Integration with AC
Sunava Dutta wrote: In offline conversations with Jonas on the topic of supporting the url syntax I think Jonas mentioned a good point regarding supporting URL for the private scenario. Namely, in caching scenarios allowing the URL to be sent in the response header if mistakes happen (for example Vary by origin header is not sent or ignored) doing so will ensure that it fails securely. I'm not so sure about the value for the public data scenario (other than consistency). Here's what I came up with, feel free to add on or elaborate. Just to clarify, your proposal is that when Access-Control-Allow-Credentials *is not* set to true we should only allow the value * for Access-Control-Allow-Origin? Whereas when Access-Control-Allow-Credentials *is* set to true we already only allow the URL syntax for Access-Control-Allow-Origin. Pros (of supporting URL syntax in public scenarios) * Supporting URL allows for a site to return data that's related to a particular site, but is non user specific (no creds) This can be accomplished either way since the server can use the Origin header if it wants to send different data for different requesting servers. I'm not really sure that that is a usecase that we have designed much around though. Cons * A better architecture here is that a site will rely on the Access-Control-Origin header to determine the site and then decide to send the data or not. Along those line it as a few teammates said it seems wasteful to support URL syntax for the public scenario as we don't want the data to be sent on the client and dumped. The server should simply not send the content if the Origin is not what is desired. Please note that the header is simply called Origin now, and has been for quite some time. * The second problem that comes to mind is that clients cannot be trusted. The resource server essentially is relying on the client to enforce the domain check. However since this is anonymous access, the client could well be evil.com's server, which would simply ignore the URL and grab data. The resource server has no way of telling who the request party really is -- it is just an anonymous HTTP client. This may instill a false sense of security for server operators. * The third challenge here is that the access-control-origin header may be spoofable therefore this scenario is not reliably solved. Like you point out, if you can't trust the client then your initial proposal for the server to look at the Origin header does not work either. However this seems to be the case no matter if we support the URL syntax for public data or not. So I don't see how this is a pro or con one way or another. All three cons you are listing seems to come down to that in the public data scenario the client can't be trusted, which does seem partially true. The way I see it is this: Pros of supporting the URL syntax for public data: * Simpler and more consistent specification. I.e. the URL syntax is always allowed and we are only forbidding the combination of wildcarding and sending cookies at the same time. * Allows a server which serves private and public data. When the server receives cookies it can customize the result for the user, when no cookies are sent it just sends back a generic response. In both cases it echoes back in the Access-Control-Allow-Origin response header the URL it received in the Origin request header. * Allows mashup sites inside a corporate firewall. These servers might serve company private data and wants to use the Access-Control spec to allow the data to be mashed up. However it does not want external websites to load such data. It does this by only echoing back in the Access-Control-Allow-Origin header the URL from the Origin header if the Origin is an intranet server. In this case the client can be trusted even in the public data case since only browsers installed on company client desktops can issue requests to the site, evil.com is blocked by the firewall. Cons of supporting the URL syntax for public data: * There is a risk of a false sense of security. I.e. a site might send private data from a URI and protect it only by sending Access-Control-Allow-Origin: trusted.com. The spec does state that such a response should not be exposed to evil.com. However if evil.com made such a request server-to-server it can of course ignore this and still read the data. A couple of notes: The last 'con' might happen anyway if the server just looks at the Origin request header and deciding whether to send the data or not based on the value of that header. So for the false sense of security argument to hold we would also be required not to send the 'Origin' header with public data requests. Similarly the 'Referer' header should not be send since it carries the same risk. The second 'serves private and public data' was something that Hixie mentioned that google might want to do in the future. If a request
RE: XDomainRequest Integration with AC
In offline conversations with Jonas on the topic of supporting the url syntax I think Jonas mentioned a good point regarding supporting URL for the private scenario. Namely, in caching scenarios allowing the URL to be sent in the response header if mistakes happen (for example Vary by origin header is not sent or ignored) doing so will ensure that it fails securely. I'm not so sure about the value for the public data scenario (other than consistency). Here's what I came up with, feel free to add on or elaborate. Pros (of supporting URL syntax in public scenarios) * Supporting URL allows for a site to return data that's related to a particular site, but is non user specific (no creds) Cons * A better architecture here is that a site will rely on the Access-Control-Origin header to determine the site and then decide to send the data or not. Along those line it as a few teammates said it seems wasteful to support URL syntax for the public scenario as we don't want the data to be sent on the client and dumped. The server should simply not send the content if the Origin is not what is desired. * The second problem that comes to mind is that clients cannot be trusted. The resource server essentially is relying on the client to enforce the domain check. However since this is anonymous access, the client could well be evil.com's server, which would simply ignore the URL and grab data. The resource server has no way of telling who the request party really is -- it is just an anonymous HTTP client. This may instill a false sense of security for server operators. * The third challenge here is that the access-control-origin header may be spoofable therefore this scenario is not reliably solved. On an issue that *May* be related, section 4.3 of the latest editors draft says, The Access-Control-Credentials HTTP response header indicates whether the response to request can be exposed when the credentials flag is true. When part of the response to an preflight request it indicates that the actual request can be made with credentials. Does this mean that credentials can only be sent in a second request or 'actual request' *after* a preflight request is sent *and* the response Access-Control-Credentials header is true? (Or can creds be sent without pre-flight? Pardon me if we discussed this prior and I've forgotten) Of course all this is assuming the credentials flag is true, which is the prerequisite. -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 10:32 AM To: Sunava Dutta Cc: Maciej Stachowiak; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC And note that this syntax should be supported even in the public data scenario. / Jonas Jonas Sicking wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, domain and host. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. / Jonas Sunava Dutta wrote: Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow- Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request
Re: XDomainRequest Integration with AC
On Jul 29, 2008, at 5:52 PM, Sunava Dutta wrote: Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. Yes. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. Jonas and I agreed offline that angle brackets are not required for unambiguous parsing. - MAciej -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url I don't think the angle brackets are necessary for forward compat, since we can just disallow spaces from the URL. - Maciej This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss- protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Re: XDomainRequest Integration with AC
Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, domain and host. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. / Jonas Sunava Dutta wrote: Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url I don't think the angle brackets are necessary for forward compat, since we can just disallow spaces from the URL. - Maciej This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss- protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Re: XDomainRequest Integration with AC
And note that this syntax should be supported even in the public data scenario. / Jonas Jonas Sicking wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, domain and host. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. / Jonas Sunava Dutta wrote: Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url I don't think the angle brackets are necessary for forward compat, since we can just disallow spaces from the URL. - Maciej This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss- protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Re: XDomainRequest Integration with AC
Adam Roben wrote: On Jul 30, 2008, at 12:19 PM, Jonas Sicking wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, domain and host. Do you mean scheme, host, and port? Yes :) / Jonas
RE: XDomainRequest Integration with AC
Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url I don't think the angle brackets are necessary for forward compat, since we can just disallow spaces from the URL. - Maciej This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss- protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Can HTTP headers encode enough URLs? (was: XDomainRequest Integration with AC)
Julian Reschke wrote: Ian Hickson wrote: On Mon, 21 Jul 2008, Julian Reschke wrote: Ian Hickson wrote: ... ...which basically just says it's a valid URL if it's a valid URI or IRI (with some caveats in the case of IRIs to prevent legacy encoding behaviour from handling valid URLs in a way that contradicts the IRI spec). This doesn't allow spaces. ... Correct. But it does allow non-ASCII characters. How do you put them into an HTTP header value? Presumably HTTP defines how to handle non-ASCII characters in HTTP as part of its error handling rules, no? Non-ASCII characters in header values are by definition ISO-8859-1. Yes, that sucks. It's not sufficient to encode all IRIs, thus you need to map IRIs to something you can use. And no, that has nothing to do with error handling. It sounds like what you are asking is if HTTP headers can encode all the values for 'url' that we need? This is different from my original concern, but is certainly a valid question. Given that we don't need to encode the all possible paths, since all paths are disallowed, is there still a concern? People would have to use punycode to encode non-ascii characters if they are part of the domain name, which is unfortunate, but hopefully tooling will help here. / Jonas
Re: XDomainRequest Integration with AC
On Mon, 21 Jul 2008, Julian Reschke wrote: ...which basically just says it's a valid URL if it's a valid URI or IRI (with some caveats in the case of IRIs to prevent legacy encoding behaviour from handling valid URLs in a way that contradicts the IRI spec). This doesn't allow spaces. Correct. But it does allow non-ASCII characters. How do you put them into an HTTP header value? Presumably HTTP defines how to handle non-ASCII characters in HTTP as part of its error handling rules, no? Non-ASCII characters in header values are by definition ISO-8859-1. Well then the answer to your question is that you use ISO-8859-1 or %-escaping. (And for legacy reasons, only %-escaping in the query part.) It's not sufficient to encode all IRIs, thus you need to map IRIs to something you can use. ASCII is sufficient to encode all IRIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XDomainRequest Integration with AC
Ian Hickson wrote: Non-ASCII characters in header values are by definition ISO-8859-1. Well then the answer to your question is that you use ISO-8859-1 or %-escaping. (And for legacy reasons, only %-escaping in the query part.) Not sure what these legacy reasons have to do with AC. Also, why you would ever want to use non-ASCII characters in an HTTP header when you need to percent-escape most code points anyway. It's not sufficient to encode all IRIs, thus you need to map IRIs to something you can use. ASCII is sufficient to encode all IRIs. Well, than the proposal should just state that people need to use RFC 3986 URIs, not the stuff HTML5 calls URL. BR, Julian
Re: XDomainRequest Integration with AC
On Jul 20, 2008, at 12:09 PM, Jonas Sicking wrote: Ian Hickson wrote: On Sat, 19 Jul 2008, Jonas Sicking wrote: According to the HTML5 spec space is a valid characted inside URLs. That wasn't intentional -- can you point to where it says that? The HTML5 spec relies on spaces not being allowed in URLs in various places. In section 2.3.2 (Parsing URLs): # Add all characters with codepoints less than or equal to U+0020 or # greater than or equal to U+007F to the unreserved production. And RFC 3986 says: # Characters that are allowed in a URI but do not have a reserved # purpose are called unreserved. These include uppercase and lowercase # letters, decimal digits, hyphen, period, underscore, and tilde. # # unreserved = ALPHA / DIGIT / - / . / _ / ~ That rule is about what conforming HTML5 UAs must do when processing a URL with error handling, it does not change what is a valid URI. In any case, even if we use the HTML5 parsing algorithm, splitting on whitespace before applying it should work. And finally, since we are not allowing a path, the main convenience reason for the error handling accepting spaces is gone. Regards, Maciej
Re: XDomainRequest Integration with AC
Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss-protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Re: XDomainRequest Integration with AC
Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss-protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) We might also want to consider simply calling the header Access-Control-Allow Since the above future expansions would make the header not just contain the origin, but also further restrictions on the origin. / Jonas
XDomainRequest Integration with AC
I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32 http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I've also heard reports of hardware frontend devices with similar limitations, although I'm not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32 http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
Re: XDomainRequest Integration with AC
On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access- Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. Regards, Maciej Namely, The changes to support the new Access control model is as follows – · Change Referer header set in the request to Origin. · Change the XDomainRequestAllowed header check from it being “1” to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I’m not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I’ll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn’t find this in the updated spec but I could be wrong. Thanks,
Re: XDomainRequest Integration with AC
On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I’ve also heard reports of hardware frontend devices with similar limitations, although I’m not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows – · Change Referer header set in the request to Origin. · Change the XDomainRequestAllowed header check from it being “1” to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I’m not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I’ll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn’t find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
Can you elaborate on the scenario you're concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Thanks! Eric Lawrence Program Manager - IE Security Want to view and tamper with HTTP(S) traffic? Try http://www.fiddler2.comhttp://www.fiddler2.com/ From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:07 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I've also heard reports of hardware frontend devices with similar limitations, although I'm not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.orgmailto:public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
Re: XDomainRequest Integration with AC
On Jul 18, 2008, at 5:15 PM, Eric Lawrence wrote: Can you elaborate on the scenario you’re concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Forms do not give you read access to the target of the redirect, whether or not it opts into Access-Control, in the cross-domain case. Regards, Maciej Thanks! Eric Lawrence Program Manager - IE Security Want to view and tamper with HTTP(S) traffic? Try http://www.fiddler2.com From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:07 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I’ve also heard reports of hardware frontend devices with similar limitations, although I’m not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I’m in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas’s proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows – · Change Referer header set in the request to Origin. · Change the XDomainRequestAllowed header check from it being “1” to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I’m not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I’ll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn’t find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
In the scenario you described, the threat was that there would be information disclosure against an unsuspecting redirector in the middle of a redirection chain. It's not clear to me how providing read-access to the final destination (which must opt-in to such access using an Access-Control response header) would somehow disclose any information about the intermediary redirector? Could you describe a simple step-by-step attack scenario? Thanks a bunch! -Eric From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 6:02 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 5:15 PM, Eric Lawrence wrote: Can you elaborate on the scenario you're concerned about? I cannot think of a scenario matching your description that could not be exploited using HTML4 Forms alone. Forms do not give you read access to the target of the redirect, whether or not it opts into Access-Control, in the cross-domain case. Regards, Maciej Thanks! Eric Lawrence Program Manager - IE Security Want to view and tamper with HTTP(S) traffic? Try http://www.fiddler2.comhttp://www.fiddler2.com/ From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:07 PM To: Eric Lawrence Cc: Sunava Dutta; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.orgmailto:public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote: The specific concern with redirections is that we know of instances where redirection systems are in use that do not currently support addition of custom response headers, and cannot be trivially updated to add such headers. These redirection systems include legacy C++ applications whose source is no longer available; the only possible updates are to the source-destination URLs via a database. I've also heard reports of hardware frontend devices with similar limitations, although I'm not personally aware of a specific device with this limitation. In general, checking the Access-control response header on every hop of a redirection chain may make the access-control specification more difficult to deploy in real-world circumstances. It seems to me that checking every hop is required to avoid inadvertent information disclosure. If someone has a service (not enabled for Access-Control) which will redirect to the URL of your choice but passing some additional info, then by forcing it to redirect to a URL that does support Access-Control you can access information that you otherwise would not be able to. We should not allow systems that don't opt in to be subject to any information disclosure, and this seems even more essential if these systems cannot be modified. Regards, Maciej -Eric From: Sunava Dutta Sent: Friday, July 18, 2008 4:21 PM To: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn Cc: public-webapps@w3.orgmailto:public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: XDomainRequest Integration with AC I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. Namely, The changes to support the new Access control model is as follows - * Change Referer header set in the request to Origin. * Change the XDomainRequestAllowed header check from it being 1 to check for Access-Control: allow * In addition, I realized that the discussions we had in the F2F (tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32) means that an access control check is now also performed when the redirect steps are applied to prevent data leakage from intranet pages. This is different from XDR as we currently do the check in the final destination for redirection. I think the reason why we did this in XDR was to allow cross domain resources to move around easily. That said, I'm not religious about this issue either way. (Adding my team-mates to hear if they have any concerns). I'll ask our dev to make the change, but before that I just wanted to confirm the AC spec will be updated with this. Currently I couldn't find this in the updated spec but I could be wrong. Thanks,
RE: XDomainRequest Integration with AC
Jonas said: 'url' is parsed as an absolute URL using the internal parser used for normal URL parsing, but if the resulting URL contains anything other than scheme, domain and port then access should be denied. I.e. if the url contains a path, a query string a fragment or similar, the header is considered invalid and MUST be ignored. This sounds fine as it reduces surface area of attack. -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 6:58 PM To: Maciej Stachowiak Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. 'url' is parsed as an absolute URL using the internal parser used for normal URL parsing, but if the resulting URL contains anything other than scheme, domain and port then access should be denied. I.e. if the url contains a path, a query string a fragment or similar, the header is considered invalid and MUST be ignored. / Jonas
