Question Pourquoi Google ajoute-t-il (1); à leurs réponses JSON?


Pourquoi Google préfixe while(1); à leurs réponses JSON (privées)?

Par exemple, voici une réponse tout en activant et désactivant un calendrier 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 un eval() dessus, mais tout ce que vous avez vraiment à faire est de remplacer le while et alors vous seriez prêt. Je suppose que la prévention d'eval est de s'assurer que les gens écrivent le code d'analyse syntaxique JSON.

J'ai vu cela utilisé dans d'autres endroits, mais beaucoup plus avec Google (Mail, Calendrier, Contacts, etc.) Bizarrement, Google Docs commence avec &&&START&&& Au lieu de cela, Google Contacts semble commencer par while(1); &&&START&&&.

Que se passe t-il ici?


3483
2018-04-19 18:00


origine


Réponses:


Ça previent JSON piratage.

Exemple contredit: disons que Google a une URL comme mail.google.com/json?action=inbox qui renvoie les 50 premiers messages de votre boîte de réception au format JSON. Les sites Web malveillants sur d'autres domaines ne peuvent pas effectuer de requêtes AJAX pour obtenir ces données en raison de la règle d'origine identique, mais ils peuvent inclure l'URL via un <script> marque. L'URL est visitée avec votre les cookies, et par substituer les méthodes de constructeur ou d'accesseur de tableau global ils peuvent avoir une méthode appelée chaque fois qu'un attribut object (array ou hash) est défini, leur permettant de lire le contenu JSON.

le while(1); ou &&&BLAH&&& empêche ceci: une requête AJAX à mail.google.com aura un accès complet au contenu du texte, et peut le dépouiller. Mais un <script> L'insertion de tag exécute aveuglément le JavaScript sans aucun traitement, ce qui entraîne une boucle infinie ou une erreur de syntaxe.

Cela ne règle pas la question de contrefaçon de requête intersite.


3760
2018-04-19 18:11



Cela empêche la divulgation de la réponse via le piratage JSON.

En théorie, le contenu des réponses HTTP est protégé par la politique de même origine: les pages d'un domaine ne peuvent obtenir aucune information à partir des pages d'un autre domaine (sauf autorisation explicite).

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

Ainsi, si vous visitez la page d'un attaquant, il ne pourra pas lire votre courrier électronique depuis gmail.com.

Sauf que lorsque vous utilisez une balise de script pour demander du contenu JSON, le JSON est exécuté en tant que Javascript dans l'environnement contrôlé d'un attaquant. Si l'attaquant peut remplacer le constructeur Array ou Object ou une autre méthode utilisée lors de la construction de l'objet, tout élément dans le JSON passerait par le code de l'attaquant et serait divulgué.

Notez que cela se produit au moment où le JSON est exécuté en Javascript, pas au moment où il est analysé.

Il y a plusieurs contre-mesures:

S'assurer que le JSON ne s'exécute jamais

En plaçant un while(1); déclaration avant les données JSON, Google s'assure que les données JSON ne sont jamais exécutées en Javascript.

Seule une page légitime pourrait réellement obtenir le contenu entier, dépouiller le while(1);, et analyser le reste en JSON.

Des choses comme for(;;); ont été vus sur Facebook par exemple, avec les mêmes résultats.

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

De même, ajouter des jetons invalides avant le JSON, comme &&&START&&&, s'assure qu'il n'est jamais exécuté.

Toujours retourner JSON avec un objet à l'extérieur

C'est OWASP manière recommandée pour protéger du détournement JSON, et est le moins intrusif.

De même que pour les contre-mesures précédentes, il s'assure que le JSON n'est jamais exécuté en Javascript.

Un objet JSON valide, lorsqu'il n'est pas entouré de quelque chose, n'est pas valide en Javascript:

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

Ceci est cependant valide JSON:

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

Donc, en vous assurant de toujours retourner un objet au plus haut niveau de la réponse, assurez-vous que le JSON n'est pas un Javascript valide, tout en étant JSON valide.

Comme noté par @hvd dans les commentaires, l'objet vide {} est valide Javascript, et savoir que l'objet est vide peut lui-même être une information précieuse.

Comparaison des méthodes ci-dessus

La méthode OWASP est moins intrusive, car elle ne nécessite aucune modification de la bibliothèque cliente et transfère des JSON valides. On ne sait pas si les bugs de navigateur passés ou futurs pourraient vaincre cela, cependant. Comme noté par @oriadam, il n'est pas clair si les données pourraient être divulguées dans une erreur d'analyse par le biais d'une erreur de traitement ou non (par exemple window.onerror).

Le fonctionnement de Google nécessite une bibliothèque client pour prendre en charge la désérialisation automatique, et peut être considérée comme plus sûre en ce qui concerne les bogues du navigateur.

Les deux méthodes nécessitent des modifications côté serveur afin d'éviter que les développeurs n'envoient accidentellement des fichiers JSON vulnérables.


442
2018-02-02 12:09



C'est pour s'assurer qu'un autre site ne peut pas faire de vilains trucs pour essayer de voler vos données. Par exemple, par remplacer le constructeur de tableau, puis en incluant cette URL JSON via un <script> tag, un site tiers malveillant pourrait voler les données de la réponse JSON. En mettant un while(1); au début, le script va se bloquer à la place.

Une demande de même site utilisant XHR et un analyseur JSON séparé, d'autre part, peut facilement ignorer le while(1); préfixe.


343
2018-05-16 02:08



Ce serait rendre difficile pour un tiers d'insérer la réponse JSON dans un document HTML avec le <script> marque. Rappelez-vous que le <script> tag est exempté de la Politique d'origine identique.


97
2018-04-19 18:04



Il empêche d'être utilisé comme la cible d'un simple <script> marque. (Bon, ça ne l'empêche pas, mais ça le rend désagréable.) De cette façon les méchants ne peuvent pas simplement mettre ce tag de script dans leur propre site et se fier à une session active pour rendre possible l'extraction de votre contenu.

modifier - notez le commentaire (et d'autres réponses). Le problème concerne les installations intégrées subverties, en particulier Object et Array constructeurs. Ceux-ci peuvent être modifiés de telle sorte que JSON inoffensif, une fois analysé, pourrait déclencher le code de l'attaquant.


65
2018-04-19 18:02



Depuis le <script> tag est exempté de la politique de même origine qui est une nécessité de sécurité dans le monde du web, alors que (1) lorsqu'il est ajouté à la réponse JSON, empêche une mauvaise utilisation de celui-ci dans le <script>marque.


3
2017-08-18 04:14