Skip to main content

JSON versus XML

Posted by robogeek on January 14, 2008 at 11:16 AM PST

Is JSON better than XML? is an interesting read. JSON is the new kid for portable data transfer and while JSON derives from Javascript there is JSON parser support in other languages. The posting goes over pro's and con's of using JSON or XML. It appears in this analysis that the big primo advantage of JSON is that browsers have an easier time using it, since XML support on browsers is "spotty" and XML support anywhere means using the DOM model which is a bit klunky. However XML has some glaring advantages what with XPath and XSLT offering powerful ways to sift through XML datasets and transform them to other formats.

Suggests to me a model of using XML for server-server interchange, and then using XSLT to transform it to JSON when squirting data to a browser.

But then he gets to security. JSON relies on using eval() to run javascript commands and that squirts out a javascript object. Um.. that looks like a gaping security problem because that JSON could contain anything and a nefarious website operator (phishing anyone?) could wreak havoc. Maybe.

He does claim that XML data is secure because There is never a possibility that parsing XML data will result in code being executed. ... uh, gee, I have been looking at SVG files recently and the W3C official SVG test suite contains SVG files that use Javascript to do animation. It appears to me that in some instances XML files do contain executable code.

Related Topics >>

Comments

"However XML has some glaring

"However XML has some glaring advantages what with XPath and XSLT offering powerful ways to sift through XML datasets and transform them to other formats."

There are a number of template libraries available for transforming JSON into HTML, as XSLT can transform XML. See http://on-web.blogspot.com/2009/12/useful-round-up-of-web-development.html

Within the domain of a simple DOM parser, XML is secure, and that's what NCZ is refering too with regards to security.

The issues that bingobibbins refers too are implementation issues (buffer overruns and what not), rather than explicit holes in the protocols. Doesn't make his point any less valid, but a buggy implementation does no make XML inherently insecure.

Since eval() is, essentially, "all" of Javascript and all of its power, it is much less secure.

This difference between XML and Javascript is much like the difference between the Common Lisp Reader and and Common Lisp Eval. The Reader reads S-Expressions in to a data structure, and Eval evaluates a data structure.

Javascript doesn't have that ability to seperate the creation of the parse tree, and the evaluation of the parse tree. It can only eval raw text.

Compare the Lisp Reader and Eval to an SVG engine being able to evaluate a stream of XML or a populated DOM.

There are mechanisms to return simply a data structure from an XML formatted data stream, and then later evaluate it using some mechanism (say, SVG). But the two parts of the process are (can be) separate.

The marshalling of the XML to the data structure is implicitly secure since there are no side effects of the processing beyond creating the DOM. Evaluating that DOM may NOT be secure because of SVGs ability to embed Javascript.

A JSON parser can be written to create data structures from JSON formatted streams, but common practice is to NOT do that as of yet, thus there is no separation between the marshalling of the data structure and the evaluation of the data structure. No ability to add ones own "firewall" so to speak.

(Note, for completeness, it is possible to embed arbitrary Common Lisp code in to an S-Expression that can be evaluated by the Reader, thus simply exposing a (read ...) function on to a socket is not secure, but the reader can be configured to not allow this.)

Every time someone proclaims "data format X is totally secure" I just hearken back to the day when it turned out a common ASN.1 parsing library had multiple security issues, making it possible to break into (among other things) Cisco routers.

The more complex the format, the more likely there are bugs... and XML is awfully darn complex, especially for what little it does. Honestly, I've never found a worthwhile use for XML versus some smaller, simpler format--and I'll be surprised if I ever do.

His point on security is wrong. There are plenty of JS libraries out there for safely parsing JSON, such as Yahoo's: http://developer.yahoo.com/yui/json/