3

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?

Jason
  • 7,612
  • 14
  • 77
  • 127
  • 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. –  Apr 25 '12 at 23:38
  • Two SO posts relating to "unparsable cruft": http://stackoverflow.com/questions/3503102/what-are-top-level-json-arrays-and-why-are-they-a-security-risk, http://stackoverflow.com/questions/3146798/why-do-people-put-code-like-throw-1-dont-be-evil-and-for-in-front-of –  Apr 25 '12 at 23:46
  • (Actually, it seems like the array-constructor hijack approach would be valid even using "unparsable cruft", if there was *any* array...) –  Apr 25 '12 at 23:50
  • @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. – Jason Apr 25 '12 at 23:56
  • @pst, first, it's not a defense against `eval`. It's a defense against third-party sites using ` – Matthew Flaschen Apr 26 '12 at 00:19
  • @MatthewFlaschen Ahh yes, I read it wrong. –  Apr 26 '12 at 04:32

1 Answers1

2

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.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
  • Where did you get the info/quotes above? – Jason Apr 25 '12 at 23:57
  • 1
    @Jason, from the article you linked, except for the RFC. Similar points are made elsewhere, however. – Matthew Flaschen Apr 26 '12 at 00:18
  • 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) – Jason Apr 26 '12 at 13:31
  • @Jason, I'd like to see those references. Also, it's easy enough to make a demonstration if there is such a vulnerability. – Matthew Flaschen Apr 26 '12 at 16:23