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
<[EMAIL PROTECTED]>
Sent by: To
public-webapi-req "[EMAIL PROTECTED]"
[EMAIL PROTECTED] <[EMAIL PROTECTED]>, "Web
API WG (public)"
<public-webapi@w3.org>
04/14/2008 09:34 cc
AM Jon Ferraiolo/Menlo Park/[EMAIL
PROTECTED],
"Close, Tyler J."
<[EMAIL PROTECTED]>, Chris Wilson
<[EMAIL PROTECTED]>, David
Ross <[EMAIL PROTECTED]>,
Doug Stamper
<[EMAIL PROTECTED]>,
Eric Lawrence
<[EMAIL PROTECTED]>,
Gideon Cohn
<[EMAIL PROTECTED]>, Ian
Hickson <[EMAIL PROTECTED]>, Jonas
Sicking <[EMAIL PROTECTED]>, Laurens
Holst <[EMAIL PROTECTED]>,
Marc Silbey
<[EMAIL PROTECTED]>,
Maciej Stachowiak <[EMAIL PROTECTED]>,
Nikhil Kothari
<[EMAIL PROTECTED]>, Sharath
Udupa
<[EMAIL PROTECTED]>,
Sunava Dutta
<[EMAIL PROTECTED]>,
Zhenbin Xu
<[EMAIL PROTECTED]>
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&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 <[EMAIL PROTECTED]>
<<inline: graycol.gif>>
<<inline: pic20752.gif>>
<<inline: ecblank.gif>>
