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

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?

> Any service which requires a client-sent Content-Type must be aware of the threat that the Content-Type header so sent is misleading and represents an attempt to attack the server.  As XDR will not allow setting of the header (a change made based on feedback from this group), there is no possibility that a service developer will mistake the request header as authoritative. 

I think you are misunderstanding the issues Ian has raised. The issue 
isn't that the server treats the Content-Type as authoritative and then 
trips over while trying to parse it, but rather that servers will sniff 
the content, misunderstand what content type it really is, and then do 
the wrong thing with it.

Off the top of my head I don't really see any security issues with the 
sniffing (although sniffing is in general bad so I wouldn't be surprised 
if there are any), but rather it just doesn't seem like a very robust 
API and something that could loose out on functionality.

> When this change is made, XDR will be unable to emit anything which could not have been sent by HTML forms.  In this way, we can demonstrate that XDR does not introduce new attack surface in the browser platform.

As well as adding much less value.

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

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?

The simplest way to authenticate fetching private data using XDR is to 
ask the user for his/her credentials and then include that as part of 
the uri in a GET request. This has two problems.

1. It means that the user will have to give his/her credentials to the 
requesting site. This fosters a culture where you hand out your password 
to 3rd party sites, something that is really unsafe.
2. Including the credentials in the uri will most likely mean that it 
will get logged in various places along the way. For example proxies as 
well as browser extensions often track uris of loaded resources.

Sure, you can say "hey, we said you shouldn't fetch private data using 
XDR, it's your own fault for doing so". However that doesn't really help 
anyone.

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.

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

But the credentials are kept away from the 3rd party site as well as 
kept out of server logs.

> <<It fails to address the majority of use cases for cross-domain data
> transfer on the Web.>>
> 
> I think this will prove to be a difficult statement to prove one way or another.  It is always challenging to enumerate the universe of current use-cases, let alone accurately predict those which will arise in the future.  We absolutely agree that it is possible to define use cases that XDR does not accommodate.  We believe that XDR enables the most common cross-domain scenarios with negligible impact to the attack surface of existing servers and the browser.
> 
> We have been contributing to the Access Control spec for some time, and we recognize the work that has gone into the CS-XHR proposal.

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.

/ Jonas

Received on Thursday, 27 March 2008 00:51:00 UTC