XDomainRequest Integration with AC

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

XDomainRequest Integration with AC

Sunava Dutta

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,

Reply | Threaded
Open this post in threaded view
|

RE: XDomainRequest Integration with AC

Eric Lawrence-4

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: [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn
Cc: [hidden email]; 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,

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Maciej Stachowiak
In reply to this post by Sunava Dutta

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,

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Maciej Stachowiak
In reply to this post by Eric Lawrence-4

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: [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn
Cc: [hidden email]; 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,

Reply | Threaded
Open this post in threaded view
|

RE: XDomainRequest Integration with AC

Eric Lawrence-4

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

 

From: Maciej Stachowiak [mailto:[hidden email]]
Sent: Friday, July 18, 2008 5:07 PM
To: Eric Lawrence
Cc: Sunava Dutta; [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; [hidden email]; 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: [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn
Cc: [hidden email]; 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,

 

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Maciej Stachowiak

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 [[hidden email]] 
Sent: Friday, July 18, 2008 5:07 PM
To: Eric Lawrence
Cc: Sunava Dutta; [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; [hidden email]; 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: [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn
Cc: [hidden email]; 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,
 

Reply | Threaded
Open this post in threaded view
|

RE: XDomainRequest Integration with AC

Eric Lawrence-4

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:[hidden email]]
Sent: Friday, July 18, 2008 6:02 PM
To: Eric Lawrence
Cc: Sunava Dutta; [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; [hidden email]; 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.com

 

From: Maciej Stachowiak [[hidden email]] 
Sent: Friday, July 18, 2008 5:07 PM
To: Eric Lawrence
Cc: Sunava Dutta; [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; [hidden email]; 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: [hidden email]; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn
Cc: [hidden email]; 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,

 

 

Reply | Threaded
Open this post in threaded view
|

RE: XDomainRequest Integration with AC

Ian Hickson

On Fri, 18 Jul 2008, Eric Lawrence wrote:

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

Let's say that there is a network of sites A, B, and C that all provide
the same feature that is Access-Control-enabled. These features are
distinguishable (i.e. you can tell which site it is from looking at the
content of the Access-Control-enabled page).

Now suppose company X every week picks one of A, B, and C, and that
knowing the pick ahead of time, if you're not an employee of company X or
sites A, B, or C can lead to some financial gain.

Now in company X's intranet, there is a server that redirects to the
Access-Control-enabled feature of the site tha will be picked in the
coming week.

A hostile user could send an e-mail or IM to an employee of company X
getting them to visit a page under the hostile user's control. That page
now just has to do a cross-domain request to the intranet page to figure
out which site will be picked in the coming week.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Jonas Sicking-2
In reply to this post by Maciej Stachowiak

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

Reply | Threaded
Open this post in threaded view
|

RE: XDomainRequest Integration with AC

Sunava Dutta

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:[hidden email]]
Sent: Friday, July 18, 2008 6:58 PM
To: Maciej Stachowiak
Cc: Sunava Dutta; [hidden email]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; [hidden email]; 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


Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Jonas Sicking-2
In reply to this post by Maciej Stachowiak

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

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Jonas Sicking-2

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

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Jonas Sicking-2

Jonas Sicking wrote:

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

Actually, after some further thought on this, even the extra
reststrictions put on the origin, is still about the origin, so keeping
the header name as is is fine with me.

But I do think we should put the '<' '>' around it.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Maciej Stachowiak
In reply to this post by Jonas Sicking-2


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


Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Jonas Sicking-2

Maciej Stachowiak wrote:

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

According to the HTML5 spec space is a valid characted inside URLs.

/ Jonas


Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Ian Hickson

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.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Julian Reschke
In reply to this post by Jonas Sicking-2

Jonas Sicking wrote:
> ...
>> I don't think the angle brackets are necessary for forward compat,
>> since we can just disallow spaces from the URL.
>
> According to the HTML5 spec space is a valid characted inside URLs.
> ...

I don't think so.

But even if this was the case, it shouldn't matter, as the URLs that
appear in AC headers should be valid RFC3986 URIs, right? Or was the
intent to "leak" non-compliant URLs into HTTP headers???

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Jonas Sicking-2

Julian Reschke wrote:

>
> Jonas Sicking wrote:
>> ...
>>> I don't think the angle brackets are necessary for forward compat,
>>> since we can just disallow spaces from the URL.
>>
>> According to the HTML5 spec space is a valid characted inside URLs.
>> ...
>
> I don't think so.
>
> But even if this was the case, it shouldn't matter, as the URLs that
> appear in AC headers should be valid RFC3986 URIs, right? Or was the
> intent to "leak" non-compliant URLs into HTTP headers???

I think that was the intent yes. I'm still not sure if this is a good
idea or not.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Jonas Sicking-2
In reply to this post by Ian Hickson

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 / "-" / "." / "_" / "~"


Reply | Threaded
Open this post in threaded view
|

Re: XDomainRequest Integration with AC

Julian Reschke

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

Only invalid HTML-URLs can contain spaces (otherwise they wouldn't be
valid IRIs).

 > ...

*But* (and that's the part I missed), most IRIs are valid HTML URLs, but
you can only put them into an HTTP header as long as they do not use
non-ISO-8859-1 characters.

So the AC spec really needs to say it's talking about RFC3986 URIs.

BR, Julian

123