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

Laurens Holst wrote:
> Close, Tyler J. schreef:
> > I've written several messages to the appformats mailing
> list. I suggest reading all of them. The most detailed
> description of the attacks are in the message at:
> >
> >
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B65
> 07@G6W0269.americas.hpqcorp.net
> >
> > with a correction at:
> >
> >
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B65
> 0D@G6W0269.americas.hpqcorp.net
>
> You do realise that with XDR, 'resource host' has no means to
> authenticate the user using (relatively secure) HTTP digest
> authentication?

I both realize and support XDR's decision to not transmit the user's HTTP auth credentials. These credentials are semantically equivalent to the use of cookies described and attacked in the references cited above.

As an aside, HTTP digest authentication is no more secure than transmission of a plaintext password. The space of user passwords is so small that a brute force attack against a password hash is feasible.

> In order to acquire the desired functionality (for which it needs the
> user's credentials), with XDR the resource host will most
> likely end up
> passing the authentication information along in the GET query string
> (bad), probably requiring the user to fill in his credentials on the
> origin site (bad), and sending the user's password plain over
> the wire
> (bad).

Since general understanding of application security is so muddled and incomplete, I have no doubt that many developers will choose to have their users give their credentials to third-party sites. Hopefully, developers for more valuable Web resources will have a better understanding of the available approaches and make better decisions. For example, one approach is similar to a one-time-use credit card number. The web page for a hosted resource includes an authorization token that the user can drag and drop onto a third party web page. This token authorizes a single request of a predetermined type. Often this user action will be required regardless of any security policy, since the third party web page will need to be told what resource it should send its request to. Both the authorization token and the resource identifier can be specified by the user in the same user interface gesture.

> I think the history of HTML has taught us that if people want to do
> something (e.g. styling), and you do not provide the means, they will
> abuse other mechanisms (tables) to achieve their goals. I can
> assure you
> people will work around the limitations of XDR in the same
> manner. The
> least we can do is provide a mechanism that lets the user do what he
> wants, yet is easy to control and secure.

I agree with the goal stated in the last sentence above and it is a significant part of my rationale for opposing the use of ambient authority. Ambient authority, as implemented by cookies and HTTP auth, is hard to control and secure, especially when user requests are created in collaboration with a third party, such as is the intended case with cross-domain browser requests. The attacks linked to above demonstrate some of these problems. In contrast, I think explicit authorization tokens can feasibly be controlled and used in a secure way, such as described in the example above.

There are many other reasons to oppose reuse of existing ambient authority mechanisms in a cross-domain request proposal. See the end of this email for another important reason.

> That is the big problem with XDR's restrictions. Well, aside from its
> breaking of REST by disallowing PUT and DELETE and setting the
> Content-Type and Accept-* headers, while favouring SOAP

I characterize the web-apps that I develop as being RESTful, and don't see any compelling value proposition in the various SOAP related specifications. The XDR proposal adequately supports all of the programming patterns that I find useful in a RESTful web browser application. This outcome doesn't seem to be accidental, but rather seems to be the result of the IE Team's approach of modelling their proposal off the defacto security policy defined by HTML 4. The prohibition against HTTP methods other than GET and POST, as well as the limitations on HTTP headers, do not originate with the XDR proposal, but rather are a carry over from the HTML 4 specification. I doubt the authors of the HTML specification intended to be creating a security policy when they specified the limitations upon the FORM element, but that is in effect what they were doing. The limitation on the FORM's method attribute to the values of "get|post" has become a security policy relied upon by Web resources. The same is true of the use of HTTP headers. We have all been building our web applications within these constraints, for as long as there has been a Web. The XDR proposal does not introduce any new limitations that we must abide by in creating web applications, and so cannot be said to break anything.

My own opinion is that the bulk of the power of the RESTful approach comes from the ability to define a custom URI namespace, do POSTs, and GETs with caching. These things are supported by the XDR proposal.

> I hope you can see why I don't share your enthusiasm for Microsoft's proposal :).

That the XDR proposal enables cross-domain requests with minimal complexity and in a way which is unlikely to cause IT administrators to disable the feature, is, in my opinion, reason enough to be enthusiastic. The XDR proposal seems like something that could be a stable platform on which to start building new kinds of applications.

I think the XDR proposal also gets some important deployment advantages from its avoidance of existing ambient authority mechanisms. Many web sites are composed of both public and private resources living inside the same URI namespace. For example, take a look at the structure of the W3C site. Both member only and public resources share the same URI namespace. Under XDR, the W3C could safely add a XDomainRequestAllowed header to all responses across the whole site. As a result, all the public resources become accessible through XDR, but the member-only resources remain protected, since XDR is unable to access or submit HTTP auth credentials. In contrast, detailed engineering work, and a corresponding security audit, would be required for the W3C to adopt the AC4CSR proposal; otherwise, the member-only resources would be vulnerable to XSRF attacks.

--Tyler

Received on Saturday, 12 April 2008 20:17:05 UTC