After reading this question as to why google/facebook etc. add unparseable cruft like:

• while(1);
• for(;;);
• &&&START&&& ... &&&END&&&
• 1 and 3 bined

to their JSON responses, I have understood the motivation. But I am still not clear as to why such relatively plex mechanisms are used, when similar effects could be achieved with things like

• adding an extra ) at the beginning for rendering the entire line invalid with a syntax error
• wrapping the JSON in ments

Now, it seems that this added protection of an infinite loop and (weird) syntax error would be to get around older and permissive javascript parsers, but I cannot seem to find any references indicating that this is the case. There is another SO question that goes on to even diss the while(1); workaround (stating the 1 can be clobbered) and reject another workaround of the form {}&&, but doesn't explain why or cite any sources.

Other references:

• , which suggests a wrapping the JSON in /*-secure-\n...*/

After reading this question as to why google/facebook etc. add unparseable cruft like:

• while(1);
• for(;;);
• &&&START&&& ... &&&END&&&
• 1 and 3 bined

to their JSON responses, I have understood the motivation. But I am still not clear as to why such relatively plex mechanisms are used, when similar effects could be achieved with things like

• adding an extra ) at the beginning for rendering the entire line invalid with a syntax error
• wrapping the JSON in ments

Now, it seems that this added protection of an infinite loop and (weird) syntax error would be to get around older and permissive javascript parsers, but I cannot seem to find any references indicating that this is the case. There is another SO question that goes on to even diss the while(1); workaround (stating the 1 can be clobbered) and reject another workaround of the form {}&&, but doesn't explain why or cite any sources.

Other references:

• http://code.google./p/fbug/issues/detail?id=369
• http://prototypejs/learn/json, which suggests a wrapping the JSON in /*-secure-\n...*/

• javascript
• json
• security

• is it just me or does this feel like security through obscurity and wouldn't even be a problem for any sanely written XSS exploit? does JSON.parse() actually call eval()? – Gung Foo Commented Feb 15, 2013 at 1:01
• A related question is why they don't just return JSON objects instead of arrays. Returning an object yields totally valid JSON that is not valid Javascript, preventing JSON hijacking in a cleaner way. The likely answer is that these services are attempting to return as pact a format as possible to save bandwidth. Most web services don't operate at quite so massive scale and could avoid this level of optimization. – Ben Regenspan Commented Dec 30, 2013 at 1:36

2 Answers 2

I think there are several details relevant to the forms of unparseable cruft:

• {}&& prefixing dates back to JSON Parsers (apparently & for example Dojo in older versions) not validating the JSON string as valid JSON Syntax. All the JSON Parser libraries I know of do validation nowadays, but this blog post from 2008 suggests that the said versions of dojo would allow to JSON.parse the json normally, while eval would simply fail, which would give you convenient protection against JSON hijacking.

• while(1) can be made ineffective using the Number prototype, by assigning 0 as 1's value.

• for(;;) and while(1) both have the effect to crash the hijacked site, which does insofar add to the protection as every further execution of any script is effectively stopped without error. This is important because an error by definition does not mark the end of script execution in javascript, while a for(;;) makes sure no script whatsoever is executed after it. This is to prevent (afaik hypothetical) situations where an attacker successfully intercepts script errors by exploiting weaknesses in window.onerror, overwriting eval, or proxying error object instantiation (like overwriting the constructor of Error.prototype).

  UPDATE

  There is also this question on security.stackexchange suggesting not to use for(;;) or while(1) since it can be implied your site is DoS-attacking the clients CPU or triggering malware scanners. I do not see a serious DoS problem with modern browsers, since they run sandboxed and on a per-Tab Basis. But it sure is a problem with older browsers. The malware scanners are a real problem and may report your site as attacking.

• &&&START&&& (and a corresponding &&&END&&& tag) make the parsing on the client side receiving the json easier than just using ) or ments that may be closed unintentionally, and may improve readability & visibility for the programmer. Wrapping in ments is just a variation of that, since it provides the /* start and the */ end tag. In my opinion, a distinct and clear mark at the start and the end helps noticing the meaning of the cruft. Using Comments is not really providing that.

About the '1 can be clobbered':

if you do the following (in webkit):

var test = 1;
console.log(test.constructor == window.Number); //true is logged

in theory there could be a possibility, that there is a way to modify window.Number or its prototype so that the value of 1 would not be 1:

window.Number.prototype.toString = function() { return 0 };
window.Number.prototype.valueOf = function() { return 0 }; 

this fortunately does not work. but i think thats what the author tries to say.

EDIT generally i would also tend to use the approach where you wrap the content into a ment (but then it must be ensured that your json object does not contain something like this {"test":"*/"} because this will create a syntax error then. and even a thrown error could be possibly be a problem, if it is catchable and probably exposing some informations about the line where the error happend. or if the Error object itself could be changed.