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>

Received on Monday, 14 April 2008 16:34:41 UTC