RE: [xml-dev] json v. xml

["Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>]

Hi.

> Maybe one of you folks with more experience in the security 
> aspects of the 
> JSON/XML business could clarify something for me.  I've heard 
> it alleged 
> that among the other attractions of JSON is that typical 
> browser security 
> policies allow one to do cross-site retrieval of JavaScript in 
> circumstances where XML retrieval would be disallowed.  Two questions:
> 
> 1. Is this true?

XML can be retrieved using the XmlHttpRequest, but only from the same
server the page in which the JS is running comes from.

JS (including JSON) can be included in the page using the script tag or
a DOM equivalent created via JS in the page.  The source from which the
script tag pulls a file full of JS source code can point to any server.

The fact that your page can easily get JS from untrusted sources but not
XmlHttp content is bizzare as far as I'm concerned.  Changing browser
policies to tighten the restrictions on the scrip tag is unlikely to
happen.

For security, I think filtering so that your JSON or JS always comes
from a trusted source is more important and more possible than filtering
the JS/JSON once it gets to the browser.

Just for the record, I think the "v." in the subject line of this thread
is a mistake.  There is no generic JSON versus XML debate outside of the
context of a particular problem.  The set of solutions where you'd hold
both technologies side by side and compare their fitness is a small
subset of all XML uses.

--->Nathan

> 2. If so, am I the only one who thinks this is bizarre?  Whatever the 
> history of these policies, we have a situation in which information 
> transmitted in the form of an executable Turing-complete programming 
> language (JavaScript) are allowed, but in which information 
> in the form of 
> a declarative markup language are blocked as a security risk?
> 
> Now, I'm not against JSON.  The other good reasons for its 
> use have been 
> mentioned in this thread.  I also understand that anyone with 
> any serious 
> interest in security will not blindly eval whatever they get back as 
> purported JSON, that the JSON subset of JavaScript is indeed 
> declarative 
> and not even close to Turing-complete.  I even agree that one 
> can transmit 
> Turing-complete code as XML (XSL comes to mind, or you can 
> put C Code in 
> into CDATA I suppose.)  The point is that almost no sensible default 
> processing of XML raises the same sorts of security issues that would 
> normally be associated with executing arbitrary JavaScript, 
> and we all 
> know that one of the ways to try and trick a JSON client is 
> to send it 
> non-JSON JavaScript..
> 
> So, insofar as my sketchy understanding of the situation is 
> correct, and 
> blithely ignoring the many compatibility issue that prevent sensible 
> changes to already-deployed systems, wouldn't it make sense 
> to ensure that 
> the security limits on cross-site downloading of script 
> fragments such as 
> JSON are at least as tight as those on XML?  Then, insofar as 
> cross site 
> access to JSON survives such changes, we could go back to 
> letting users 
> choose whichever format makes them happier in a given situation.
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> ______________________________________________________________
> _________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>