Chris Wilson wrote:
Indeed, there has been a lot of back and forth on the topics of XDR
and XHR2+AC over the last couple of weeks.
As others have pointed out, it hasn't so much been a back-and-forth as
much as the rest of the group asking Microsoft for detailed information
and waiting for answers.
This message is not
attempting to set forth in detail all the objections we have had;
Sunava will deliver that 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;
I don't think expectations are extremely high. We simply want
information that is detailed enough that it can be used as basis for
technical discussions and changes to the spec.
So far the input has mostly been "We are worried about the security
implications of AC+XHR and think XDR is safer". That is not enough to
make any changes to the Access-Control spec to address those worries.
The rest of the group does not even know *what* the worries are.
that takes
much time to prepare, and involves a number of people here across
multiple teams. Some of these concerns are direct and technical, and
might be fixed in the XHR2+AC draft; however, some of our most
important concerns pertain to the approach of enabling cross-domain.
Not really sure what this means, but I'm hoping that Sunava will explain
in his email what these concerns are.
Given that the whole Access-Control spec is about enabling cross-domain,
saying that that is the part you have concerns with doesn't really
narrow things down :)
However, we
feel the design of grafting cross-domain access on to the
already-existing XHR system is dangerous,
Why? The new-XDR-API vs. reuse-existing-XHR-API discussion does not seem
related to security. Though given the lack of specifics so far there
isn't much for me to go on here.
and the current design is
being arrived at by the method of discussing what developers want to
do, then trying to make it safe, rather than starting with what is
secure by principle and incrementally adding functionality.
Experience has taught us it is much easier to ship a system that is
secure by design and add functionality than try to secure a
implementation after it ships by rolling back features.
I don't know what you mean by "secure by principal" and "secure by
design" here. Are you alluding to the fact that XDR can never send out
requests that aren't possible already?
If so, that seems like it would only be "secure by design" as far as
securing the server goes. Not as far as protecting the users data goes,
which seems just as important.
I would argue that Access-Control is better at protecting the users data
than XDR. Since XDR isn't built for transferring private data (since it
doesn't send cookies) it forces web developers to develop their own
mechanisms on top of XDR. Most likely many of these mechanisms are going
to be less safe than Access-Control since they are unlikely to spend as
much effort and expertise securing their mechanism compared to how much
has been put into Access-Control.
Removing a tool to do safe cross-site private data transfer doesn't mean
that sites will stop doing it. It just means that they will use other
mechanisms.
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, and challenging to imagine
that there are no other headers in use by servers anywhere around the
world that might not be good to access.
How would the fact that same-site XHR is already deployed affect how we
can deploy cross-site XHR? Is your concern that sites today attempt to
do cross-site XHR requests and rely on the fact that that throws?
Also, is this a security concern, or a concern that AC+XHR will break
existing pages?
In our opinion, one of the fundamental problems with the XHR2+AC
proposal is that it blithely reuses an already-existing API for
same-domain communication, and then attempts to patch the cracks that
appear when it is used to perform cross-domain transfers.
Again, why is this a problem? Even if we were to go with the security
model of XDR, I would strongly advocate that we would use XHR as the API
to access this security model.
The discussion about the security model and the discussion about the API
seems like two orthogonal discussions to me (with the security model
discussion being far more interesting), and I would prefer if we
discussed them separately.
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] Nor
is it an “incompatible proposal,” [4]
Why? The fact that the two APIs are nearly identical seems to indicate
that they are.
But again, the API discussion seems separate from the security model one.
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]. This message did not claim
to reflect a deep technical analysis of its contents of the Access
Control draft, but let’s lay aside that concern; it is far more
germane that there was no indication that we saw at the time that this
access control mechanism would be simply directly applied to the
XMLHttpRequest object.
So does that mean that if we removed the ability to specify custom
headers and custom HTTP methods then microsoft have no security concerns
with the spec? That really was what changed when XHR was combined with
Access-Control.
We’ve given the feedback that we believe this approach to enabling
cross-domain is inherently insecure, but unfortunately the working
group has not been receptive to these lessons we have learned from our
experience.
We have received no input to the WG about what microsofts experience is.
Will Sunavas email detail this too?
For example, one response was: “I'm also not sure how you
could be surprised by the WGs vote not to replace years worth of work
with a completely different and incompatible proposal. Especially
when any security concerns could have been addressed by tweaks to the
existing specification.” [8] In my opinion, this response is flawed
on multiple levels; first, because we had never recommended throwing
away all work on XHR2+AC and replacing it with XDR; we’ve suggested
that XDR is a focused subset of cross-domain functionality that we
believe is securable today. Certainly, XHR2+AC attempts to enable a
lot more functionality; that would assure its place in the future.
So you are not so much opposed XHR2+AC as you say that we should do both?
Secondly, I would think that issues of security in design would make
it obvious that more work is necessary; just because something has
been around for a year doesn’t mean it’s right, or that it is the best
way of doing something.
I agree that just because something has been around for a longer time
doesn't make it better. However I'm still not sure how you could be
surprised that the group would give up years worth of work to replace it
with a new dropped in proposal, rather than by making the changes you
felt were needed to the existing proposal.
The communication we got from microsoft wasn't "we think the following
things are wrong with the existing proposal for the following reasons,
and thus suggest these changes", but rather "we think think this thing
we have here is better than your thing, oh, and btw, we've already put
our thing in IE8 and plan to keep it there". That is hardly working with
the W3C.
Finally, we disagree that the security
concerns about XHR2+AC can be addressed by mere tweaks to the
technical details. For example, I pointed out that the flow of this
design is inherently open to DNS rebinding attacks [9],
These DNS rebinding attacks are already possible using normal same-site
XHR today. I also note that you never replied to my reply in that
thread: http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0117.html
Something that unfortunately has been a common theme :(
It is still unknown to me if microsofts concern can be accomplished by
mere tweaks to the spec. Simply because I don't know what the concern is
with the various differences between the spec.
For example the fact that the site has no ability to choose who to
enable cross site requests for, is that an intentional difference?
Or the fact that cookies are not sent? What was your concern there? (I
have my own concerns with cookies as has been, and is still being
discussed on this list).
as well as
other issues we’ve pointed out. I believe we have several times laid
out some of our concerns with the current XHR2+AC method of doing
cross-domain; it continues to be claimed that “nobody has responded to
the requests for a description of these problems” [10].
For example in the thread mentioned above.
I don’t
believe that’s appropriate; I think whenever we do describe where we
see design flaws and potential exploit area (e.g. [11])
You do describe where you see flaws. But you don't describe what flaws
you are seeing, or why you think they are flaws. Saying "there is a
problem with that part of the spec" just leaves us guessing what you
want changed.
At any rate, focusing on individual technical issues misses the point;
spackling security over existing designs to extend them in ways they
were not intended is very complex to get right.
Without discussion individual technical issues I don't see how we could
discuss the merits of one proposal vs the other. Having meta discussions
about "we've designed our spec with security by principal" doesn't
really take us any further. Of course every one involved has had
security as their main concern.
To address these concerns, we built a simpler, more focused API to
enable some set of cross-domain access we felt could be secured, in
the most focused way possible. Unlike Access Control, XDR is modeled
off the defacto security policy defined by HTML 4.0 – that is, the
prohibition against HTTP methods other than GET and POST and
limitations of HTTP headers are in the HTML 4.0 specification and
widely used as Tyler Close from HP pointed out to the Web API mailing
list. [16] Indeed, the Open Ajax Alliance claims that XDR promises
to be simpler and more secure [17].
As has been mentioned before, just because you are only issuing requests
that HTML 4.0 can already do doesn't make it an inheritly safer spec.
You're leaving the responsibility of identify control up to the
websites, and by removing the Content-Type header you force servers to
guess the content type which also have security problems.
/ Jonas
