W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

Re: XDR *API* Security Impact

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Mon, 14 Apr 2008 09:52:03 -0700
To: Thomas Roessler <tlr@w3.org>
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>, "Close, Tyler J." <tyler.close@hp.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>
Message-ID: <OF023C2D76.943275E3-ON8825742B.005B92D0-8825742B.005CA84E@us.ibm.com>

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.


             Thomas Roessler                                               
             Sent by:                                                   To 
             public-webapi-req         "public-appformats@w3.org"          
             uest@w3.org               <public-appformats@w3.org>, "Web    
                                       API WG (public)"                    
             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                        
                                       Eric Lawrence                       
                                       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                         
                                       Maciej Stachowiak <mjs@apple.com>,  
                                       Nikhil Kothari                      
                                       <nikhilko@microsoft.com>, Sharath   
                                       Sunava Dutta                        
                                       Zhenbin Xu                          
                                       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">

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

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

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:


Thomas Roessler, W3C  <tlr@w3.org>

(image/gif attachment: graycol.gif)

(image/gif attachment: pic20752.gif)

(image/gif attachment: ecblank.gif)

Received on Monday, 14 April 2008 16:55:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:10:00 UTC