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
