26

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:

Community
  • 1
  • 1
Manav
  • 9,066
  • 6
  • 35
  • 50
  • 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 Feb 15 '13 at 01: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 compact 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 Dec 30 '13 at 01:36

2 Answers2

10

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.

Community
  • 1
  • 1
Beat Richartz
  • 9,034
  • 1
  • 28
  • 49
3

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.

t.niese
  • 32,069
  • 7
  • 56
  • 86
  • in fact, your point about the syntax error leaking information is probably the reason why merely prefixing the JSON with an invalid string is a bad idea. So that rules out the first option (using a simple `)` prefix before the JSON) that I've suggested, but then what is the `&&&START&&& ... &&&END&&&` doing. – Manav Feb 06 '13 at 08:44
  • @Manav well one thing, but thats just a guess is, that using `for(;;)` or `while(1)` in combination with `&&&START&&&` is to first try to stop the execution of the script, with a syntax error. and if this does not work, at least block the malicious site with the endless loop. but to be honest, i also need to do some further reading again. but i think everything that could be parsed as code or throw exception could be bad. – t.niese Feb 06 '13 at 09:25
  • @Manav an additional note is (but thats also just a guess): because current js engines do much preprocessing and optimization before initial executing the code , it is not clear - without knowing the internals of the code of the engine - when and how objects in the code are initialized. thats why i would think wrapping the json result into a comment it the better solution. – t.niese Feb 06 '13 at 09:35