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

Question

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?

Firman

None of these have anything to do with JSON. If someone wishes to use eval, then the burden of fixing the approach is entirely on them... also, the article date from 2008 when proper JSON parsing was not as prevalent on browsers. Today it is either standard JSON.parse or readily available as a shim. I would not go for such "security" measures. – Christo

Two SO posts relating to "unparsable cruft": #3503602, #3147298 – Christo

(Actually, it seems like the array-constructor hijack approach would be valid even using "unparsable cruft", if there was any array...) – Christo

@pst - curious as to why you wouldn't - both google and facebook use these methods as an extra layer of security. And although more modern browsers are secure, we still get traffic from older browsers. – Firman

@pst, first, it's not a defense against eval. It's a defense against third-party sites using <script src>. Second, if the script doesn't parse, the array can't be constructed, so JSON hijacking will fail. – Wivern

@MatthewFlaschen Ahh yes, I read it wrong. – Christo

Answer 1

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.

Wivern

Where did you get the info/quotes above? – Firman

@Jason, from the article you linked, except for the RFC. Similar points are made elsewhere, however. – Wivern

I have also expressed this to the internet architect, however they have stated that they have read other articles referencing that hijacking can still take place on json responses with top level opbjects (which was my argument - if all responses have a top level argument, then that in effect, makes them secure) – Firman

@Jason, I'd like to see those references. Also, it's easy enough to make a demonstration if there is such a vulnerability. – Wivern