JSON unparseable cruft: Why so serious?

问题:

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

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

to their JSON responses, I have understood the motivation. But I am still not clear as to why such relatively complex 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 comments

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.com/p/fbug/issues/detail?id=369
• http://prototypejs.org/learn/json, which suggests a wrapping the JSON in /*-secure-\n...*/

回答1:

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 comments that may be closed unintentionally, and may improve readability & visibility for the programmer. Wrapping in comments 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.

回答2:

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 comment (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.