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&&&
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
)
at the beginning for rendering the entire line invalid with a syntax error 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:
/*-secure-n...*/
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.
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.