jsonsecurityparsingtaint

Increase security by creating un-eval-uatable ("unparsable cruft") JSON?


we are looking at using the unparseable curft approach to our json as an extra level of security.

In looking at the approaches, I've come across google's while(1); and facebook's for(;;); and then another mention of {}&&

I've seen comments surrounding the while(1); that say the 1 being numeric can get clobbered, so my approach was going to be the for(;;);.

Then I came across the {}&&, which renders the json as invalid yet it can still be parsed/eval'ed. See this article for reference: http://www.sitepen.com/blog/2008/09/25/security-in-ajax/

What are your approaches? and what do your functions look like for making the ajax call with the unparseable curft?


Solution

  • I just always use a root object. As noted:

    It is only possible to hijack JSON data with a root that is an array. When the root is a primitive, primitive values do not trigger a constructor. When the root is an object, it is not valid JavaScript syntax, and therefore can’t be parsed.

    Note that having a root primitive (e.g. your response is just 5) is not valid JSON. Section 2 of the RFC says:

    A JSON text is a serialized object or array.

      JSON-text = object / array
    

    This isn't much of a burden, as I (and many sites) typically use an envelope format. E.g.:

    {
      "header": {...},
      "data": {...}
    }
    

    or:

    {
      "status": {...},
      "data": {...}
    }
    

    etc.

    In that case, any array would just be the value of data, so you can serve syntactically valid JSON without any hijacking risk.