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:mjs@apple.com]
Sent: Friday, July 18, 2008 6:02 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 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<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<mailto:annevk@opera.com>; jonas@sicking.cc<mailto:jonas@sicking.cc>; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org<mailto: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<mailto:annevk@opera.com>; jonas@sicking.cc<mailto:jonas@sicking.cc>; Sharath Udupa; Zhenbin Xu; Gideon Cohn
Cc: public-webapps@w3.org<mailto: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,