W3C home > Mailing lists > Public > public-appformats@w3.org > March 2008

RE: What is Microsoft's intent with XDR vis--vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 26 Mar 2008 23:56:58 +0000 (UTC)
To: Eric Lawrence <ericlaw@exchange.microsoft.com>
Cc: "Web API WG (public)" <public-webapi@w3.org>, "public-appformats@w3.org" <public-appformats@w3.org>
Message-ID: <Pine.LNX.4.62.0803262347120.12521@hixie.dreamhostps.com>
On Wed, 26 Mar 2008, Eric Lawrence wrote (reformatted to follow Internet 
standards for mail quoting):
> > 
> > This is blatently untrue, a number of serious security problems with 
> > XDR have already been raised (such as the fact that it encourages 
> > content-type sniffing
> Vis--vis content-type sniffing, it was plainly stated that Content-Type 
> sniffing is neither recommended, nor necessary.

Stating this doesn't make it true. You are requiring that content be sent 
as text/plain regardless of the actual content type. This is a blatent 
violation of HTTP semantics, and requires that servers use non-standard 
methods (such as sniffing or assumption) to determine the type of data 
being sent. This is a security vulnerability. Given the number of times IE 
has been the subject of security flaws due to Content-Type sniffing, one 
would have thought you'd be more sensitive to this issue. :-)

> In this way, we can demonstrate that XDR does not introduce new attack 
> surface in the browser platform.

This has been repeatedly shown to be untrue.

> > the fact that it encourages people to pass their credentials to 
> > untrusted third parties).
> XDR is a truly anonymous request and does not send credentials to ANY 
> site (1st party, 3rd party), trustworthy or not.

Exactly. This thus requires that if a page on host A wants to contact host 
B on behalf of the user, host A needs to ask the user for his credentials 
on host B, an extremely dangerous practice.

A _safe_ mechanism would allow the user to give the credentials to host B 
directly without host A having to ask the user for those credentials.

> In this way, we have high confidence that there is no possibility of 
> executing a CSRF attack against an unsuspecting legacy server which uses 
> cookies or HTTP authentication.

But, as Jonas has pointed out, it is, in addition to the two problems I've 
listed above, also vulnerable to CSRF in intranet environments, which is 
possibly even more serious.

> This can be contrasted with the CS-XHR proposal, in which credentials 
> ARE automatically passed to 3rd party servers.

This is, as the old adage goes, a feature, not a bug. It certainly isn't a 
security issue -- XHR with Access-Control is not subject to CSRF, even on 
intranets, due to the requirement that servers (host B) be contacted 
first, before carrying out the request, to confirm that they are able to 
handle data from the third party (host A).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 26 March 2008 23:58:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:22 UTC