RE: IE Team's Proposal for Cross Site Requests

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.   `._.-(,_..'--(,_..'`-.;.'