Pourquoi Google précéder while(1) ; leurs réponses JSON ?

Question

C'est quelque chose que j'ai toujours été curieux, c'est exactement pourquoi Google ajoute while(1); de leur (privé) réponses JSON.

Par exemple, voici une réponse tout en tournant un calendrier sur Google Agenda:

while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
  ['remindOnRespondedEventsOnly','true'],
  ['hideInvitations_remindOnRespondedEventsOnly','false_true'],
  ['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]

Je suppose que c'est pour empêcher les gens de faire une eval() sur elle, mais tout ce que tu aimerais vraiment avoir à faire est de remplacer le tout et puis tu serais fixé. Je suppose eval prévention est de s'assurer que les gens écrivent sûr JSON code d'analyse.

Je l'ai vu utilisé dans quelques autres endroits, aussi, mais beaucoup plus avec Google (Mail, Calendrier, Contacts, etc.) Curieusement, Google Docs commence par &&&START&&& au lieu de cela, et les Contacts Google semble commencer avec while(1); &&&START&&&.

Personne ne sait ce qui se passe ici?

Answer 1

Il empêche JSON détournement.

Artificiel exemple: Google a une URL de la forme mail.google.com/json?action=inbox qui renvoie les 50 premiers messages de votre boîte de réception au format JSON. Le mal de sites sur d'autres domaines peuvent pas faire des requêtes AJAX pour obtenir ces données en raison de la même origine, mais ils peuvent inclure l'URL via un <script> balise. L'URL est visité avec vos cookies, et par des raisons impérieuses le tableau global constructeur ou aux méthodes d'accès , ils peuvent avoir une méthode est appelée à chaque fois qu'un objet (tableau ou hachage) attribut est défini, ce qui leur permet de lire le contenu JSON.

L' while(1); ou &&&BLAH&&& empêche: une requête AJAX à l' mail.google.com disposent d'un accès complet au contenu du texte, et peut-bande. Mais un <script> balise d'insertion à l'aveuglette exécute le JavaScript sans aucun traitement, résultant en une boucle infinie ou une erreur de syntaxe.

Ce n'est pas la question de la cross-site request forgery.

Answer 2

Il empêche la divulgation de la réponse en JSON détournement.

En théorie, Google réponses JSON sont protégés par la Même Origine: les pages d'un domaine ne peut pas obtenir toutes les informations à partir des pages web sur un autre domaine (sauf si explicitement autorisé).

Un attaquant peut demander des pages sur d'autres domaines, en votre nom, par exemple en utilisant un <script src=...> ou <img>balise, mais il ne peut pas obtenir aucune information sur le résultat (en-têtes, contenu).

Ainsi, une page de l'attaquant ne pouvait pas lire votre e-mail de gmail.com lors de la visite.

Sauf que lors de l'utilisation d'une balise de script pour demander le contenu JSON, le JSON est exécuté en Javascript dans un agresseur environnement contrôlé. Si l'attaquant peut remplacer le Tableau ou l'Objet constructeur ou d'une autre méthode utilisée lors de la construction d'objets, rien dans le JSON passera par un code malveillant, et être divulgués.

Notez que ce qui se passe au moment le JSON est exécuté comme Javascript, pas au moment où elle est analysée.

Il y a plusieurs contre-mesures:

S'assurant que le JSON n'est jamais exécuté

En plaçant un while(1); déclaration avant le JSON de données, Google permet de s'assurer que les données JSON n'est jamais exécutée comme Javascript.

Seulement légitime de la page pourrait effectivement obtenir l'ensemble du contenu, de la bande de l' while(1);, et d'analyser le reste de JSON.

S'assurant que le JSON n'est pas valide Javascript

De même, l'ajout d'invalide les jetons avant le JSON, comme &&&START&&&, fait en sorte qu'il n'est jamais exécutée.

Toujours retour JSON avec un Objet à l'extérieur

C'est - OWASP recommandé pour protéger du JSON, du détournement et la moins intrusive.

De façon similaire à la précédente contre-mesures, il permet de s'assurer que le JSON n'est jamais exécutée comme Javascript.

Un JSON valide objet, une fois n'est pas entouré par quoi que ce soit, n'est pas valide en Javascript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

Ce n'est cependant valable JSON:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

Donc, assurez-vous toujours renvoyer un Objet le plus haut niveau de la réponse permet de s'assurer que le JSON n'est pas valide Javascript, tout en restant JSON valide.

Comparaison des méthodes ci-dessus

L'OWASP moyen est moins intrusif, qu'il n'a pas besoin de la bibliothèque du client changements, et les transferts JSON valide. Il n'est pas sûr que le passé ou l'avenir navigateur bugs pouvaient vaincre cela, cependant.

Google de la manière nécessite de la bibliothèque du client pour prise en charge automatique de la sérialisation, et peut être considéré comme plus sûr à l'égard de bogues de navigateur.

Les deux méthodes nécessitent des modifications de serveur dans le but d'éviter aux développeurs d'envoi accidentel vulnérables JSON.

Answer 3

C'est pour assurer quelques autres site ne peut pas faire de vilains tours à essayer de voler vos données. Par exemple, en remplaçant le constructeur array, puis y compris JSON URL via un <script> balise, un malveillant site tiers pourrait voler les données de la réponse JSON. En mettant un while(1); au début, le script va s'accrocher à la place.

Un même site demande de l'aide XHR et un parser JSON, d'autre part, peut facilement ignorer l' while(1); préfixe.

Answer 4

Ce serait rendre difficile pour un tiers d’insérer la réponse JSON dans un document HTML avec le tag. N’oubliez pas que le tag est exempté de la Même origine politique.

Answer 5

Il empêche d’être utilisé comme cible d’un simple `` tag. (Eh bien, il ne l’empêche, mais il le rend désagréable). De cette façon méchants ne vient de mettre cette balise de script dans leur propre site et s’appuient sur une session active pour permettre de récupérer votre contenu.