Re: XDR *API* Security Impact

Thomas,
Good points. Incidentally, when OpenAjax Alliance discussed XDR vs Access
Control, Doug Crockford (inventor of JSONRequest) was in the room, and his
preferences were in order JSONRequest, XDR and Access Control. We didn't
ask for opinions on 3 technologies, just 2 (i.e., XDR and Access Control),
I'm not sure how others at OpenAjax Alliance would vote if asked to choose
between JSONRequest and XDR.

You highlight an important use scenario (JSON data) and a common
programming requirement (conversion of JSON data into JavaScript objects).
As you say, the JSONRequest spec requires that JSON data be parsed in a
manner that doesn't allow for direct execution of JS logic because it
requires a JSON parser. (The exact text says: "A request will fail if the
response is not strictly in JSON format. ")

Three scenarios are fine with me: (1) Adopt XDR and its general thrust, but
review its details critically (e.g., missing PUT, DELETE, https), or (2)
Adopt JSONRequest and its general thrust, but review its details critically
(e.g., only allows JSON data natively - XML data must put into something
like an "xml:" property), or (3) greatly simplify Access Control, pretty
much keeping its name but making radical changes to adopt approaches closer
to XDR or JSONRequest.

Jon




                                                                           
             Thomas Roessler                                               
             <tlr@w3.org>                                                  
             Sent by:                                                   To 
             public-webapi-req         "public-appformats@w3.org"          
             uest@w3.org               <public-appformats@w3.org>, "Web    
                                       API WG (public)"                    
                                       <public-webapi@w3.org>              
             04/14/2008 09:34                                           cc 
             AM                        Jon Ferraiolo/Menlo Park/IBM@IBMUS, 
                                       "Close, Tyler J."                   
                                       <tyler.close@hp.com>, 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>, Sharath   
                                       Udupa                               
                                       <Sharath.Udupa@microsoft.com>,      
                                       Sunava Dutta                        
                                       <sunavad@windows.microsoft.com>,    
                                       Zhenbin Xu                          
                                       <zhenbinx@windows.microsoft.com>    
                                                                   Subject 
                                       XDR *API* Security Impact           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





One question that hasn't come up much is the security impact of the
XDR *API* in likely deployments.  I'd like to look at that a bit
more in this message...


Specifically, XDR is aiming at the kinds of cross-site data flows
for which we currently use cross-site script tags.  I.e., the user
runs a web application from a.com that wants to access data from
b.com.  The same-origin policy will preclude a direct XMLHttpRequest
to b.com.  Leaving postMessage (and fragment based messaging) aside
for the moment, the common programming pattern for this use case is
for a.com/sample.html to have code that adds a script tag like this
to its DOM:

             <script src="http://b.com/data.js?callback=cb&amp;param=foo">
             </script>

I.e., a script is loaded from b.com, and executed. That script is
then expected to call the function cb, and passes the data that are
retrieved to that function.

Notably, execution control passes to the data provider, so the data
provider (b.com) exercises full control over the web application
running at a.com/sample.html.  That's undesirable from a security
perspective, and in fact one of the motivations behind proposals
like XHR2 and XDR: For a cross-site API to be useful, it should
enable a programming paradigm on the client that enables
a.com/sample.html to read the data *without* passing execution
control to b.com.


XMLHttpRequest2 achieves this requirement for XML data, when the
parsed response information can be retrieved from the responseXML
property.

For JSON, web application programmers are left to their own devices
by XHR2, and will more often than not end up using eval to parse the
JSON data that they have retrieved, effectively again passing
execution control to b.com.



The JSONRequest API gets this point right: The programming paradigm
there passes a JavaScript object to a callback function, and it's
relatively trivial to write safe client-side code.



XDR leaves web application programmers to their own devices under
all circumstances: The response is parsed out of a "responseText"
property, period.

The security gain over the script tag pattern fully depends on
programmers knowing very precisely what they do: either, parsing
JSON safely (good luck), or parsing XML in the browser, portably,
and then dealing safely with the DOM that comes back from that.

One common lazy programmer's pattern for that parsing step is
actually abusing innerHTML as an XML parser -- which is just about
as bad as eval, as it enables adding event handlers which can then
be used to execute arbitrary javascript code.



So, in summary, using XDR securely from a web application takes more
effort and attention than is desirable, with common and easy
programming patterns leading to a usage that is as insecure as the
programming pattern that's replaced by it.

XHR2 behaves well when the content that is retrieved consists of
HTML or XML data (which it frequently well), but causes trouble with
JSON.

JSONRequest is the least error-prone of the three APIs, because it
has a straight-forward programming model.


Incidentally, the same considerations apply to postMessage; see:

http://lists.w3.org/Archives/Public/public-html-comments/2008Apr/0000.html

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>