Re: IE Team's Proposal for Cross Site Requests

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

Received on Saturday, 24 May 2008 00:12:56 UTC