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

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