RE: IE Team's Proposal for Cross Site Requests

> -----Original Message-----
> From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org]
> On Behalf Of Arun Ranganathan
> Sent: Wednesday, May 14, 2008 7:01 PM
> To: public-webapi@w3.org; public-appformats@w3.org
> Subject: Re: IE Team's Proposal for Cross Site Requests
>
>
> Chris,
>
> 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?

[Sunava Dutta] Sure, I'm compiling this as we speak. I expect this to be ready and available to the Web API by mid June in the latest. (Sorry for the time, my resources are spread thin over several AJAX features) I don't think there should be any surprises here as we have communicated our concerns before. However, there does seem to be the scope to provide specific concerns which we will do where we can or elaborate on a few, as well as our security principles for a good cross domain solution and where AC fails or meets them. This does not change what Chris said though. Just because there are not existing threats (although the URL canonicalization issue as Eric Lawrence discovered is currently open?) does not mean that AC is safe. We can present threats and they can be patched. That's just not something we recommend. A good threat modeled solution I'm sure many of us will agree is secure by design. That's our overarching point we've been trying to get across.
>
>  >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
>
> http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html
>
> 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.

[Sunava Dutta] You're missing the point. I'm agnostic to a block or allow list. What I've been asking for in case it's not been clear is the rationale as to why these are blocked in the spec. There are threads going on regarding this. My point is that blocking headers on shipped implementations is hard, since it's difficult for us to patch legacy versions. The current XHR spec should not be an academic exercise and should rightfully model existing UA's. That said doing the right thing for security is important, but we need to have good justifications. Currently that is absent in the case of the blocked headers.
>
>  >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
>
[Sunava Dutta] Wildcarding was a problem in Flash (one of many?). I'm not sure if AC is vulnerable to that but it certainly seems possible? The point here is that a number of developers won't ready the security notes on the docs and inadvertently expose their services. Solutions should be coded for the lowest common denominator. That's hard to understand given that most Web API participants are quite technical.
http://jeremiahgrossman.blogspot.com/2006/10/crossdomainxml-statistics.html

> http://lists.w3.org/Archives/Public/public-webapi/2008May/0196.html
>
> you suggest we look at "DNS Hardening" for "clues." Can you be a bit
> more specific here, if possible?
>
[Sunava Dutta] The write-up I'm compiling will investigate the DNS rebinding issue in more detail. I think that's fair. If DS rebinding is raised as a concern, we should be able to give a specific threat or in the minimum a potential mechanism. I'm not a security guru here and I expect my security team can give me a proper assessment of the risk of AC here, although it seems with the two step request here and the requirement of sites to validate the host header, TOCTOU and DNS rebinding risks are high.

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

[Sunava Dutta] Fair enough. As mentioned, the IE sec team will try to detail the exact risk if any (for DNS Rebinding) or give a risk assessment here by June 15th.
>
> Regarding URL Canonicalization, a proposal to address URL
> canonicalization problems by disabling Access-Control-Policy-Path:
>
> http://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html
>
> 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.

[Sunava Dutta] Both having a restricted list or an allow list is challenging. My point is, block allowing script to send http headers cross domain. A restricted list needs to grow with time as more are discovered. Browsers need to deploy patches to service existing versions.
An allow list that can send headers cross domain CANNOT guarantee that services today may not expect this come from XHR and consequently assume it's same origin.
If one takes into account 'new cross domain behaviors' are potentially scary by themselves, it gets even worse when one models the intersection of them. (For example, have the AC proposers modeled the affects of looking at sending cross domain headers, credentials etc holistically?)
>
>  >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
> needs.
>
> <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 we've 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. :)
>
[Sunava Dutta] If we can agree on the security principles (hopefully the F2F) hopefully a safe way to do AC can be developed. These are certainly scenarios that this feature is useful for that's why we're proposed XDR alongside. Although we invented XHR here we've been concerned about using it cross domain as mentioned before. I think the uber point with CS-XHR is the behavior is different in the two modes (same site and cross domain). That's confusing enough.

> 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.
>
[Sunava Dutta] Agreed.
>
>  >We will of course continue to participate in the Web API WG's 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
> security.
>
> We desire this also. Specifics help illustrate points best.
>
[Sunava Dutta] Again, specifics will be provided however I reiterate, don't expect a stream of specifics to ensure that solution is ready to ship. Taking a few steps back and looking at what's possible today and what a secure cross domain solution should guarantee is more important. (A long long time ago, the IE team thought that having no active threats for the product covered us from the security front for shipping. That was not a good strategy -:))

> -- A*
>
>

Received on Thursday, 15 May 2008 23:27:51 UTC