Information Technology News.


The message-parsing JSON format can be a bit cumbersome at times

Share on Twitter.

Sponsered ad: Get a Linux Enterprise server with 92 Gigs of RAM, 16 CPUs and 8 TB of storage at our liquidation sale. Only one left in stock.

Sponsered ad: Order the best SMTP service for your business. Guaranteed or your money back.

November 1, 2016

Ask anybody that has worked with the message-parsing JSON format and they will most likely tell you there's plenty of security issues and various stability problems for those that are unfamiliar with JavaScript Object Notation (JSON) code.

That friendly advice comes from software engineer Nicholas Seriot, who last week presented his thesis on JSON parsers to an audience at Geneva's 2016 Soft-Shake Conference.

Although JSON's inventor, Douglas Crockford, wanted to create something that was concise and unchangeable, the world didn't agree and that sure didn't help.

There are now no less than six documents that describe JSON, with differences between all of them, and as a result, no two parsers are quite alike.

In this post, Seriot created a suite of test files, fired them at a bunch of parsers, and found that “edge cases and maliciously crafted payloads can cause bugs, crashes and denial of services, mainly because JSON libraries rely on specifications that have evolved over time and that left many details loosely specified or not specified at all.”

Seriot was thorough – the parsers he fired his tests at included:

  • Five parsers written in C – JSMN, Jansson, CCAN, cJSON, and JSON-parser;
  • Three Objective-C parsers – JSONKit, TouchJSON, and JSON-Framework;
  • Three Java parsers – Gson, Jackson, and Simple JSON;
  • Apple's JSONSerialisation parser;
  • The Freddy parser written in Swift;
  • A Bash script, JSON.sh;
  • Parsers written in R, Go, Python, JavaScript, Perl, and Rust.
  • His overall basic assessment: “Out of over thirty JSON parsers, no two parsers did the same set of documents the same way”.

    The full results are here-- A “red” entry in the table means that Seriot's test crashed the parser. And that's bad news since crashes can lead to security threaths.

    A “brown” entry-– “parsing should have succeeded but failed” is also dangerous, “because an uncontrolled input may prevent the parser to parse a whole document”. We'll see how that pans out in the next few weeks.

    Source: Nicholas Seriot.


    Sponsered ad: Get a Linux Enterprise server with 92 Gigs of RAM, 16 CPUs and 8 TB of storage at our liquidation sale. Only one left in stock.

    Sponsered ad: Order the best SMTP service for your business. Guaranteed or your money back.

    Share on Twitter.

    IT News Archives | Site Search | Advertise on IT Direction | Contact | Home

    All logos, trade marks or service marks on this site are the property of their respective owners.

    Sponsored by Sure Mail™, Avantex and
    by Montreal Server Colocation.

           © IT Direction. All rights reserved.