Re: [xml-dev] json v. xml

[Rick Marshall <rjm@zenucom.com>]

Nathan Young -X (natyoung - Artizen at Cisco) wrote:
> 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.
>   
Not true - that's the whole point for doing mashups. And you can use 
XmlHttpRequest in effect to get or send anything. JSON and XML aren't 
the security problem XmlHttpRequest is. In particular it can be run from 
"onload" in the body tag which means the poor user is screwed from the 
minute they access the site.

Can we just clear up a few more things: 1. JSON is data structures (like 
XML) not objects (CS 101 - where are create/destroy/methods etc?). 2. 
Like it or not, verbose end tags means XML has a degree of redundancy 
that ensures correct structure - {} do not do that - and in large 
documents and data files I see this as critical. 3. JSON also includes 
lots of useless redundancy - " everywhere is just the start, so are the 
limited and simple data types (why not include dates and times? it is 
the 21C after all).

Rick

> 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
>>
>>     
>
> _______________________________________________________________________
>
> 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
>
>
>