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

Re: XDR *API* Security Impact

From: Thomas Roessler <tlr@w3.org>
Date: Mon, 14 Apr 2008 19:17:39 +0200
To: Kris Zyp <kris@sitepen.com>
Cc: public-appformats@w3.org, "Web API WG (public)" <public-webapi@w3.org>, Jon Ferraiolo <jferrai@us.ibm.com>, "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>
Message-ID: <20080414171739.GU345@iCoaster.does-not-exist.org>

On 2008-04-14 10:59:27 -0600, Kris Zyp wrote:

> AFAIK, Crockford's json.js library is effective in validating
> javascript such that JSON data can be properly executed without
> allowing arbitrary code execution. In addition, I would be
> surprised if we don't see native JSON evaluaters in browers in
> the next rev of browsers. Therefore, I don't think is a problem.
> We have effective means for safely parsing JSON data, as long as
> we have a mechanism for loading the text.

The question is whether people are going to use these kinds of
interfaces.  If badly set defaults like the ones in the prototype.js
JavaScript framework, the kind of code that's found all over the
place in dashboard widgets, and the kind of howtos that are common
online are any predictor of future behavior, then an API that just
gives developers a string when they want structured data *is* going
to keep the issues around.


BTW, even json.org still presents eval as the first choice -- of
course with some remarks about competent and trustworty data
sources, but with an overall relatively weak admonishment.

In any event, that's a side track.  The point is that the XDR API
will lead lots of Web developers down the slippery slope when that's
simply unnecessary.

> That being said, I would love to see XHR2 include an additional property 
> getter for "responseJSON" that provided access to safely natively parsed 
> JSON. It is kind of silly that XHR provides responseXML, when most modern 
> devs are using JSON.

I don't know whether "most modern devs are using JSON", and I am not
a hugesx fan of it as a format, but actually agree that it's common
enough (and a common enough source of troubles) that it warrants
attention in APIs.

More generically, I don't think that new cross-origin APIs that
"just return a string" (but are clearly intended for structured
data) should be standardized (or shipped) given the experience
that's available.

Thomas Roessler, W3C  <tlr@w3.org>
Received on Monday, 14 April 2008 17:18:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC