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:mjs@apple.com]
> Sent: Friday, July 18, 2008 5:07 PM
> To: Eric Lawrence
> Cc: Sunava Dutta; annevk@opera.com; jonas@sicking.cc; 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: annevk@opera.com; jonas@sicking.cc; 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,
>