Re: XDR *API* Security Impact

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.

  http://www.prototypejs.org/api/string#method-evaljson

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.

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

Received on Monday, 14 April 2008 17:18:13 UTC