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

I think the XDR proposal is pretty good and is the best of the current proposals to push forward to standardization. I hope Microsoft finds a way to make that happen.

Some responses to Jonas' comments are inline below...

Jonas Sicking wrote:
> Eric Lawrence wrote:
> > Ian--
> >
> > Thanks for sharing your opinions.  I'd like to take the
> opportunity to clarify a few points of confusion.
> >
> > <<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
> >
> > It's possible that you overlooked some mails on the thread?
> >
> > Vis-à-vis content-type sniffing, it was plainly stated that
> Content-Type sniffing is neither recommended, nor necessary.
>
> I think you are misunderstanding the issues Ian has raised.
>
> Since XDR does not let you set the Content-Type header, the
> server is in
> fact required to sniff the content type. How else would the server
> figure out the content type of the request body?

I think Eric's point is that the client specified Content-Type header cannot be trusted to accurately describe the content, so the server must parse the content under the assumption that the header is misleading. Given that status-quo, and assuming the resource only accepts one Content-Type, omitting the header doesn't seem to change the server's responsibilities.

There could be a danger when the resource accepts more than one media type and the server determines that the client sent a different media type than the client thought it was sending. In this case, the server sees the client as saying something that the client didn't mean to say. To avoid this scenario, there would have to be some mechanism agreed to between the client and the server for specifying the intended media type. This role is precisely what the Content-Type header was created for, but it has unfortunately been overloaded with security implications. Having client and server coordinate the media type based on a URL query string argument seems like the best alternative.

> > XDR is a truly anonymous request and does not send
> credentials to ANY site (1st party, 3rd party), trustworthy
> or not.  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.
>
> Again, this is not the concern. The concern is sites that do want to
> transport private data. They are going to try to do this weather the
> browser provides the API meant for this or not.

Sending the user's cookies, as AC4CSR does, is just not a viable design, since the target resource cannot determine whether or not the user consented to the request. I've posted several explanations of the attacks enabled by this use of ambient authority, and, in my opinion, the issues are still outstanding. The use of ambient authority in AC4CSR is a show-stopper, as reflected in the decision Mozilla announced on this mailing list.

> In fact, I would argue that XDR does encourage sending private data.
> Most use cases for POST that I can think of involves knowing who the
> data is coming from. Or have you had other use cases in mind?

There are many other ways to authorize a request, other than sending the user's credentials, which is among the worst ways.

> Additionally, it is not true that no authorization
> credentials is being
> sent. Intranet sites might authorize simply based on the fact that you
> can connect to the intranet server. I have still not seen anything in
> the XDR spec to prevent internet->interanet POSTs so this
> still seems to
> be the case.

Currently, an HTML form can POST internet->intranet with Content-Type of "application/x-www-form-urlencoded" or "text/plain". The XDR proposal adds a third case of no specified Content-Type (but with no cookies or custom headers). It seems highly unlikely that an intranet resource correctly defends against the first two cases, but is vulnerable to the third. I would rather bet on this than work through all the things that might go wrong with AC4CSR's pre-flight request, caching, ACLs and use of ambient authority.

> I definitely appreciate all the work that Microsoft has put into the
> spec, but am saddened that there was no mention about XDR in
> any of the
> numerous posts from anyone at microsoft.

I think the AC4CSR spec is a goner, and so appreciate Microsoft stepping up with a proposal that seems more likely to survive study and deployment. Given the Mozilla announcement, now seems like the right time to move on from the AC4CSR proposal.

--Tyler

"IHTMLXDomainRequest Interface ()"
<http://msdn2.microsoft.com/en-us/library/cc288108(VS.85).aspx>

"Access Control for Cross-site Requests"
<http://www.w3.org/TR/access-control/>

Received on Wednesday, 2 April 2008 23:55:08 UTC