From : Ian Hickson < : Ian Hickson < ian@hixie.ch



To : Chris Wilson < : Chris Wilson < Chris.Wilson@microsoft.com

Cc : " : " public-webapi@w3.org " < public-webapi@w3.org

Message-ID : <Pine.LNX.4.62.0805110822400.22257@hixie.dreamhostps.com>



On Fri, 9 May 2008, Chris Wilson wrote: > > Sunava will deliver [all the objections we have had] in a concise form. > From the comments in various responses in this topic, it is clear that > expectations are extremely high for the level of detail in those > objections; that takes much time to prepare [...] I don't think anyone expects Microsoft's long-promised feedback to be any more detailed than anyone else's feedback. Sunava said last November that this feedback would be sent as soon as possible. As far as I know, nobody else spent six months writing up their feedback. > 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 This is FUD -- there is nothing difficult to deploy about this, since cross-site XHR has never been available before. Not only that, but the only headers that are blocked by XHR2/AC and are not blocked by regular XHR today are the Cookie and Cookie2 headers, and that is actually the subject of outstanding feedback on the same-domain XHR spec rather than anything particularly specific to cross-domain XHR. > and [it is] challenging to imagine that there are no other headers in > use by servers anywhere around the world that might not be good to > access. Actually the great thing about the way the AC spec is designed is that we don't have to imagine this -- we can guarantee it. No headers under author control are ever sent to a server until the server opts in to this cross-domain mechanism explicitly. > Cross-domain access in Flash has had a trail of bugs for these reasons > [1]. Sunava will detail these security principles; I believe the > XHR2+AC approach can currently be demonstrated to violate these. Even > the AC draft itself has a list of security concerns and vague > requirements as observed and discussed in the group [2]. > [1] http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html > [2] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0150.html This is all FUD -- the Flash issue is irrelevant here as we are by design avoding the policy file problem altogether (so we couldn't even have the old Flash 9 vulnerabilities if we tried), and the e-mail you cite above is just an e-mail from your team with vague unspecified security concerns, not a citation of vague requirements in the spec. (For example, Sunava in that e-mail suggests that same-site and cross-site XHR having different behaviour is bad design, despite the fact that the solution you are advocating doesn't only have different behaviours but has an entirely different API, and then goes on to incorrect interpret suggestions in the AC spec as being requirements on XHR2 implementations, possibly misunderstanding that XHR2 itself clearly specifies all the requiremenets unambiguously for the cross-domain case and the same-domain case.) > 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) This is again FUD. Your team has been vaguely saying that these threats exist in the XHR2/AC proposal since last year, and yet nobody from Microsoft has ever actually shown a clear vulnerability. Reciting a litany of threat model terms without showing actual attack scenarios is not any kind of reasonable argument. > We want to be extremely clear that XDR is most definitely NOT, in our > opinion, a “slightly different API that solves nearly the same > problem” – neither is it “different for no extra benefit.” [3] > [3] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0205.html It is clearly not radically different. It has almost the same method names, for instance. It is indeed different for no extra benefit. It is in fact a subset of the behaviour possible with XHR2. (It's also worth reiterating the point made in the e-mail you cite above, namely that XDR has a slew of security problems itself, unlike the XHR2+AC proposal, despite your implication that XDR is "secure by design" and that XHR2+AC is "dangerous".) > Nor is it an “incompatible proposal,” [4] since it’s not intended > to be merged with XHR or Access Control; it can happily coexist. > [4] http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html It is incompatible because it has slightly different semantics, meaning that an implementation of one would not trivially be portable to an implementation of the other. It is also incompatible from an author mindshare point of view. (For other parties who haven't realised what's going on here: the idea is that by introducing new and subtly different APIs in the Web platform, in the guise of providing "next enabling needs" functionality, authors will find the Web platform to be more confusing and thus less attractive than, say, Silverlight. It's an obvious "poison pill" play.) > As for the XHR2+AC draft itself, I don't believe we intended anything we > ever said to equate to “XHR2+AC is good;" I challenge the assertion of > “Microsoft reviews W3C spec as good” [5] as an accurate > generalization of what has been said [6]. > [5] http://www.w3.org/2008/Talks/0421-ac-tbl/#(4) > [6] http://lists.w3.org/Archives/Public/public-appformats/2007May/0029.html "Eric, who is one of our networking experts, and I have reviewed the draft and we think it looks good" is pretty unambiguous. > Microsoft has had increasing concerns over the security of the design of > this proposal. These concerns come from painfully learned lessons about > browser security, as we have seen many examples of how violating some > basic security principles has led to vulnerabilities in the past. I think it is pretty poor form to imply that Microsoft, who have only just returned to the browser space, somehow has experience that outweighs the experience of the three other browser vendors who are involved in the development of this specification, especially since those vendors have been active for far longer, and have a far better track record of security with their browsers. > Finally, we disagree that the security concerns about XHR2+AC can be > addressed by mere tweaks to the technical details. It's hard for us to know whether they could or not since you and your team has continually failed to actually precisely specify what the security concerns _are_, despite promising them for six months! > For example, I pointed out that the flow of this design is inherently > open to DNS rebinding attacks [9], as well as other issues we’ve > pointed out. > [9] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html This is further FUD. As Jonas pointed out in his reply to your e-mail, the attack you describe doesn't actually have anything to do with XHR2 [9a], and as he further describes in a later e-mail, the feature you incorrectly say is vulnerable is in fact a security feature that is protecting against attacks that XDR in fact has no protection against at all [9b]. I notice you didn't reply to either of those e-mails. [9a] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0117.html [9b] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0118.html > The responses I’ve seen to the issues we have shared on this list have > typically been dismissive that there is a problem – or presumptive > that the problem can simply be spackled over. When we do go down > detailed discussions, the threads seem to disappear (e.g. [12]). > [12] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/050.html Assuming you mean 0150, not 050 (which would never have been a valid thread), that e-mail has two replies, neither of which got a further reply from Microsoft. Similarly, the thread I cite above ([9a], [9b]) was a reply to your e-mail, but there was no further reply from Microsoft. If any threads are disappearing, I respectfully suggest the blame lies with your team, not anyone else. > 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 feedback we > might get before we must lock down for release). As we’ve said, we'd > welcome feedback on XDR, and if it is timely enough, it could be > incorporated into our IE8 product. It is such blatent disregard for the Web standards process that really reinforces for us Microsoft's deep commitment to interoperability. Such ultimatums are also not a very good way of obtaining cooperation from the wider Web standards community -- if you wonder why you are often faced with hostility and dismissal, I would suggest this attitude is the cause. > We desire interoperability; we cannot enable that at the expense of > security. Given that XDR has had a number of very serious security vulnerabilities described on this mailing list, you may wish to reconsider deploying XDR if security really is a goal. At least the following security problems have been detailed so far: * XDR allows POSTs of arbitrary content to intranet servers, without server-side opt-in. * XDR will foster an environment in which sites request user credentials for third-party sites from users (since it doesn't provide a way to do anything else), resulting in an environment where users blithely give their passwords to any sites that ask for them, causing phishing and fraud to skyrocket (we're already seeing the lack of a credential-capable cross-site API do this, e.g. see linkedin.com). * XDR forces all content sent in POST entity bodies to be labeled as Content-Type: text/plain, regardless of the type, forcing servers to ignore the Content-Type header and apply sniffing heuristics to detect the actual type of the content sent, potentially leading to privilege escalation attacks (e.g. if the user thinks he's uploading a PNG but the server sniffs it as an HTML file and sends it back as such). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'