Why does Google prepend while 1 to their JSON responses

Question

Why does Google prepend while 1   to their  private  JSON responses   For example  here s a response while turning a calendar on and off in Google Calendar   while  1         u           smsSentFlag    false          hideInvitations    false          remindOnRespondedEventsOnly    true          hideInvitations remindOnRespondedEventsOnly    false true          Calendar ID stripped for privacy    false          smsVerifiedFlag    true            I would assume this is to prevent people from doing an eval   on it  but all you d really have to do is replace the while and then you d be set  I would assume the eval prevention is to make sure people write safe JSON parsing code   I ve seen this used in a couple of other places  too  but a lot more so with Google  Mail  Calendar  Contacts  etc   Strangely enough  Google Docs starts with  amp  amp  amp START amp  amp  amp  instead  and Google Contacts seems to start with while 1    amp  amp  amp START amp  amp  amp    What s going on here

User · Answer

As this is a High traffic post i hope to provide here an answer slightly more undetermined to the original question and thus to provide further background on a JSON Hijacking attack and its consequences

JSON Hijacking as the name suggests is an attack similar to Cross-Site Request Forgery where an attacker can access cross-domain sensitive JSON data from applications that return sensitive data as array literals to GET requests. An example of a JSON call returning an array literal is shown below:

[{"id":"1001","ccnum":"4111111111111111","balance":"2345.15"}, 
{"id":"1002","ccnum":"5555555555554444","balance":"10345.00"}, 
{"id":"1003","ccnum":"5105105105105100","balance":"6250.50"}]

This attack can be achieved in 3 major steps:

Step 1: Get an authenticated user to visit a malicious page. Step 2: The malicious page will try and access sensitive data from the application that the user is logged into.This can be done by embedding a script tag in an HTML page since the same-origin policy does not apply to script tags.

<script src="http://<jsonsite>/json_server.php"></script>

The browser will make a GET request to json_server.php and any authentication cookies of the user will be sent along with the request. Step 3: At this point while the malicious site has executed the script it does not have access to any sensitive data. Getting access to the data can be achieved by using an object prototype setter. In the code below an object prototypes property is being bound to the defined function when an attempt is being made to set the "ccnum" property.

Object.prototype.__defineSetter__('ccnum',function(obj){

secrets =secrets.concat(" ", obj);

});

At this point the malicious site has successfully hijacked the sensitive financial data (ccnum) returned byjson_server.php JSON

It should be noted that not all browsers support this method; the proof of concept was done on Firefox 3.x.This method has now been deprecated and replaced by the useObject.defineProperty There is also a variation of this attack that should work on all browsers where full named JavaScript (e.g. pi=3.14159) is returned instead of a JSON array.

There are several ways in which JSON Hijacking can be prevented:

Since SCRIPT tags can only generate HTTP GET requests, only return JSON objects to POST requests.
Prevent the web browser from interpreting the JSON object as valid JavaScript code.
Implement Cross-Site Request Forgery protection by requiring that a predefined random value be required for all JSON requests.

so as you can see While(1) comes under the last option. In the most simple terms, while(1) is an infinite loop which will run till a break statement is issued explicitly. And thus what would be described as a lock for the key to be applied (google break statement). Therefore a JSON hijacking, in which the Hacker has no key will be consistently dismissed.Alas, If you read the JSON block with a parser, the while(1) loop is ignored.

So in conclusion, the while(1) loop can more easily visualised as a simple break statement cipher that google can use to control flow of data.

However the key word in that statement is the word 'simple'. The usage of authenticated infinite loops has been thankfully removed from basic practice in the years since 2010 due to its absolute decimation of CPU usage when isolated (and the fact the internet has moved away from forcing through crude 'quick-fixes'). Today instead the codebase has preventative measures embedded and the system is not crucial nor effective anymore. (part of this is the move away from JSON Hijacking to more fruitful datafarming techniques that i wont go into at present)

*

User · Answer

That would be to make it difficult for a third-party to insert the JSON response into an HTML document with the  lt script gt  tag  Remember that the  lt script gt  tag is exempt from the Same Origin Policy

User · Answer

Note  as of 2019  many of the old vulnerabilities that lead to the preventative measures discussed in this question are no longer an issue in modern browsers   I ll leave the answer below as a historical curiosity  but really the whole topic has changed radically since 2010      when this was asked     It prevents it from being used as the target of a simple  lt script gt  tag   Well  it doesn t prevent it  but it makes it unpleasant    That way bad guys can t just put that script tag in their own site and rely on an active session to make it possible to fetch your content   edit  mdash  note the comment  and other answers   The issue has to do with subverted built-in facilities  specifically the Object and Array constructors  Those can be altered such that otherwise innocuous JSON  when parsed  could trigger attacker code

User · Answer

It prevents JSON hijacking  a major JSON security issue that is formally fixed in all major browsers since 2011 with ECMAScript 5   Contrived example  say Google has a URL like mail google com json action inbox which returns the first 50 messages of your inbox in JSON format  Evil websites on other domains can t make AJAX requests to get this data due to the same-origin policy  but they can include the URL via a  lt script gt  tag  The URL is visited with your cookies  and by overriding the global array constructor or accessor methods they can have a method called whenever an object  array or hash  attribute is set  allowing them to read the JSON content   The while 1   or  amp  amp  amp BLAH amp  amp  amp  prevents this  an AJAX request at mail google com will have full access to the text content  and can strip it away  But a  lt script gt  tag insertion blindly executes the JavaScript without any processing  resulting in either an infinite loop or a syntax error   This does not address the issue of cross-site request forgery

User · Answer

It prevents disclosure of the response through JSON hijacking  In theory  the content of HTTP responses are protected by the Same Origin Policy  pages from one domain cannot get any pieces of information from pages on the other domain  unless explicitly allowed   An attacker can request pages on other domains on your behalf  e g  by using a  lt script src     gt  or  lt img gt  tag  but it can t get any information about the result  headers  contents   Thus  if you visit an attacker s page  it couldn t read your email from gmail com  Except that when using a script tag to request JSON content  the JSON is executed as JavaScript in an attacker s controlled environment  If the attacker can replace the Array or Object constructor or some other method used during object construction  anything in the JSON would pass through the attacker s code  and be disclosed  Note that this happens at the time the JSON is executed as JavaScript  not at the time it s parsed  There are multiple countermeasures  Making sure the JSON never executes By placing a while 1   statement before the JSON data  Google makes sure that the JSON data is never executed as JavaScript  Only a legitimate page could actually get the whole content  strip the while 1    and parse the remainder as JSON  Things like for      have been seen at Facebook for instance  with the same results  Making sure the JSON is not valid JavaScript Similarly  adding invalid tokens before the JSON  like  amp  amp  amp START amp  amp  amp   makes sure that it is never executed  Always return JSON with an Object on the outside This is OWASP recommended way to protect from JSON hijacking and is the less intrusive one  Similarly to the previous counter-measures  it makes sure that the JSON is never executed as JavaScript  A valid JSON object  when not enclosed by anything  is not valid in JavaScript  eval    quot foo quot   quot bar quot        SyntaxError  Unexpected token    This is however valid JSON  JSON parse    quot foo quot   quot bar quot        Object  foo   quot bar quot    So  making sure you always return an Object at the top level of the response makes sure that the JSON is not valid JavaScript  while still being valid JSON  As noted by  hvd in the comments  the empty object    is valid JavaScript  and knowing the object is empty may itself be valuable information  Comparison of above methods The OWASP way is less intrusive  as it needs no client library changes  and transfers valid JSON  It is unsure whether past or future browser bugs could defeat this  however   As noted by  oriadam  it is unclear whether data could be leaked in a parse error through an error handling or not  e g  window onerror   Google s way requires a client library in order for it to support automatic de-serialization and can be considered to be safer with regard to browser bugs  Both methods require server side changes in order to avoid developers accidentally sending vulnerable JSON

User · Answer

This is to ensure some other site can t do nasty tricks to try to steal your data  For example  by replacing the array constructor  then including this JSON URL via a  lt script gt  tag  a malicious third-party site could steal the data from the JSON response  By putting a while 1   at the start  the script will hang instead   A same-site request using XHR and a separate JSON parser  on the other hand  can easily ignore the while 1   prefix

User · Answer

After authentication is in place  JSON hijacking protection can take a   variety of forms  Google appends while 1  into their JSON data  so   that if any malicious script evaluates it  the malicious script enters   an infinite loop    Reference  Web Security Testing Cookbook  Systematic Techniques to Find Problems Fast

User · Answer

Since the  lt script gt  tag is exempted from the Same Origin Policy which is a security necessity in the web world  while 1  when added to the JSON response prevents misuse of it in the  lt script gt  tag

[javascript] Why does Google prepend while(1); to their JSON responses?

Examples related to javascript

Examples related to json

Examples related to ajax

Examples related to security