- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Mon, 14 Apr 2008 08:07:10 -0700
- To: "Close, Tyler J." <tyler.close@hp.com>
- Cc: Chris Wilson <Chris.Wilson@microsoft.com>, David Ross <dross@windows.microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Eric Lawrence <ericlaw@exchange.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, Laurens Holst <lholst@students.cs.uu.nl>, Marc Silbey <marcsil@windows.microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Nikhil Kothari <nikhilko@microsoft.com>, "public-appformats@w3.org" <public-appformats@w3.org>, "Web API WG (public)" <public-webapi@w3.org>, public-webapi-request@w3.org, Sharath Udupa <Sharath.Udupa@microsoft.com>, Sunava Dutta <sunavad@windows.microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>
- Message-ID: <OFFD5F68AE.30DD2E3A-ON8825742B.004EB9D4-8825742B.00530DCD@us.ibm.com>
Hi Tyler, I agree with many of your arguments below. To me, it boils down to three issues, security, simplicity, and architecture. I believe security concerns trump all others, and my analysis is that Microsoft's security team made the right calls with the XDR proposal, taking the conservative approach where no headers, cookies or other credentials are transmitted to other domains, and the policy enforcement point (PEP) is assumed to be on the server. This aligns with the de facto security model for today's Web where a user establishes trust with the single domain, where the user and that domain share secret information only between themselves, such as the information stored in cookies. At OpenAjax Alliance, we have a Security Task Force which contains some industry experts on web security issues and the strong consensus (different than unanimity) was a preference for XDR, mainly for security reasons. On the simplicity side, XDR is appropriately simple (roughly as simple as JSONRequest), whereas Access Control has incrementally added complexity (syntax rules for allowing/denying domains, two-step dance for POST requests, detailed lists of headers that are transmitted) to the point that it is now a small beast. On the architecture side, Access Control is just plain wrong, with the PEP on the client instead of the server, which requires data to be sent along the pipe to the client, where the client is trusted to discard the data if the user isn't allowed to see the data; it is just plain architecturally wrong to transmit data that is not meant to be seen. Regarding the criticsm of XDR with more complex workflows where two sites need to work in coordination with each other, possibly including the use of cookies from the two sites, there are lots of ways to skin that cat and for security reasons (such as CSRF concerns) should not be done within the context of the cross-domain request mechanism. For example, HTML5 allows postMessage(), so you can set up a web page with two IFRAMES, each talking to a different server, and have them do client-side communications via postMessage(); also, there are various server-side alternatives to address these scenarios. Regarding the criticism of XDR for not supporting PUT and DELETE, to me those complaints are minor and fixable. Given that MS has proposed that XDR be taken up by W3C, add an issue about whether XDR should support PUT and DELETE. The one negative with XDR is the process by which Microsoft proposed it, where they were largely silent during the many months that the Access Control spec evolved, only to unleash an alternate proposal at a late stage. Microsoft instead should have been involved in the Access Control activity from its early stages. However, we shouldn't punish the Web by choosing the wrong technical approach just because of how Microsoft engaged in the discussion. Given all of the above, my preference would be for W3C to take XDR to Recommendation and drop Access Control as this would be better for the Web community due to better approaches to security, simplicity, and architecture. It is clear from the thousands of emails on this list that others have different opinions, but that's what mine is. Jon "Close, Tyler J." <tyler.close@hp.c om> To Sent by: Laurens Holst public-webapi-req <lholst@students.cs.uu.nl> uest@w3.org cc Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, 04/12/2008 01:13 Eric Lawrence PM <ericlaw@exchange.microsoft.com>, Sunava Dutta <sunavad@windows.microsoft.com>, Ian Hickson <ian@hixie.ch>, "Web API WG (public)" <public-webapi@w3.org>, "public-appformats@w3.org" <public-appformats@w3.org>, Chris Wilson <Chris.Wilson@microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Marc Silbey <marcsil@windows.microsoft.com>, David Ross <dross@windows.microsoft.com>, Nikhil Kothari <nikhilko@microsoft.com> Subject 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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic30332.gif
- image/gif attachment: ecblank.gif
Received on Monday, 14 April 2008 15:10:31 UTC