Re: IE Team's Proposal for Cross Site Requests


Thanks for the email. A few points below:

 >This message is not attempting to set forth in detail all the 
objections we have had; Sunava will >deliver that in a concise form.

Can you give us a ballpark ETA on this?

 >For example, today the current XHR draft proposes to block a list of 
headers that are unsafe >only in a cross-domain context; however, this 
is difficult to deploy since XHR has already >shipped, and challenging 
to imagine that there are no other headers in use by servers anywhere 
 >around the world that might not be good to access.

Microsoft feedback on proposals such as

are welcome. Also, I'm not averse to discussing a restricted list of 
headers that the XHR API *should* support rather than a block list.

 >There are fundamental cross domain security principles that we firmly 
believe need to be >guaranteed by a cross domain solution; otherwise, 
our experience leads us to believe there will >be exploits found over 
time. Cross-domain access in Flash has had a trail of bugs for these 
 >reasons [1]. Sunava will detail these security principles;

*In particular* what is the direct parallel you are drawing between the 
Flash approach and the XHR2+AC approach? Sunava's commentary eagerly 
awaited. In this message

you suggest we look at "DNS Hardening" for "clues." Can you be a bit 
more specific here, if possible?

 >Even if current vulnerabilities like exposure to Time of Check, Time 
of Use, >DNS Rebinding >attacks, and URL path canonicalization issues 
can be patched (rather than >ignored),

I think we ought to make spec. language and related docs. good for 
server-side deployment of the Access-Control scheme as well, and 
encourage good Web architecture. DNS Rebinding is a generally powerful 
attack that creates a fair number of vulnerabilities outside the scope 
of XHR+AC, and we should encourage servers to respect origin headers 
and/or use TLS, but I'm still trying to figure out your notions of a 
demonstrable vulnerability that is specific to our approach within XHR2+AC.

Regarding URL Canonicalization, a proposal to address URL 
canonicalization problems by disabling Access-Control-Policy-Path:

has been put on the table.

 > For example, is there a blocklist of headers? If so, how will this be 
maintained as the list of >discovered headers grows?

Again, feedback on an "acceptable headers to exchange" component of AC 
is welcome. Also again: I'm not averse to discussion of using a 
restricted list of headers in lieu of blocked ones, if you think that 
will help.

 >XDR is not intended to be a competitor >to XHR2+AC; it is different by 
design, and is >focused on a much smaller set of cross-domain >access 

<snip />

 >I do want to be clear, since there was some confusion based on a 
conversation between Charles >and Michael Champion  we will be shipping 
our XDR implementation in IE8 (modified by >any fsafeedback we might get 
before we must lock down for release). As weve said, we'd >welcome 
feedback on XDR [18], and if it is timely enough, it could be 
incorporated into our >IE8 product.

All things being equal, it is likely that XDR and XHR2+AC will co-exist, 
and the major JS libraries can probably straddle the difference. Of 
course, I'd prefer it if we had a single API that addressed the more 
robust needs of web applications, including Cookies, etc. :)

But IE8 beta does support postMessage, just as other UAs do. And it 
would seem that postMessage will be used for cross-site requests because 
of the widespread support across UAs, modulo caller/callee understanding 
across sites (e.g. there's likely to be a propagation of iframe-based 
APIs which can be requested with Cookies, Auth, etc. and on which other 
sites will call .postMessage). This would have well-known limitations. 
Coming to the table and commenting on proposals will create better 
solutions for developers.

 >We will of course continue to participate in the Web API WGs work on 
cross-domain access, >and I hope that work can be made secure to our 
satisfaction (and therefore implementable in >IE); but we simply cannot 
implement APIs that we believe expose customers to security >exploits. 
We desire interoperability; we cannot enable that at the expense of 

We desire this also. Specifics help illustrate points best.

-- A*

Received on Thursday, 15 May 2008 08:19:01 UTC