javascript - sheet - symfony owasp




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

Étant donné que la <script> est exemptée de la politique de même origine, qui est une nécessité de sécurité dans le monde Web, while(1) lorsqu'elle est ajoutée à la réponse JSON, empêche son utilisation abusive dans la <script> .

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

Par exemple, voici une réponse lors de l'activation et de la désactivation d'un calendrier dans Google Agenda :

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

J'imagine que c'est pour empêcher les gens de faire un eval() dessus, mais tout ce que vous auriez à faire est de remplacer le while , puis vous serez réglé. Je suppose que la prévention eval consiste à s'assurer que les utilisateurs écrivent du code d'analyse syntaxique JSON sécurisé.

Je l’ai déjà utilisé à d’autres endroits, mais beaucoup plus avec Google (courrier, agenda, contacts, etc.). Étrangement, Google Docs commence par &&&START&&& place, et Google Contacts semble commencer par while(1); &&&START&&& while(1); &&&START&&& .

Que se passe t-il ici?


Cela permet de s’assurer que certains sites ne peuvent pas faire d’astuces pour voler vos données. Par exemple, en remplaçant le constructeur de tableau , puis en incluant cette URL JSON via une <script> , un site tiers malveillant pourrait voler les données de la réponse JSON. En mettant un while(1); au début, le script sera bloqué à la place.

En revanche, une requête utilisant le même site utilisant XHR et un analyseur JSON distinct peuvent facilement ignorer le while(1); préfixe.


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

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

Un attaquant peut demander des pages sur d'autres domaines en votre nom, par exemple, en utilisant une <script src=...> ou <img> , 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 email provenant de gmail.com.

Sauf que lorsque vous utilisez une balise de script pour demander du contenu JSON, celui-ci est exécuté en tant que Javascript dans l'environnement contrôlé par l'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 du code JSON transiterait 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 de son analyse.

Il existe 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 peut réellement obtenir le contenu entier, déshabiller while(1); et analysez le reste en tant que 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, l'ajout de jetons non valides avant le JSON, comme &&&START&&& , permet de s'assurer qu'il n'est jamais exécuté.

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

Ceci est le moyen recommandé par OWASP de se protéger du piratage JSON et est le moins intrusif.

De la même manière que 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 entouré par rien, n'est pas valide en Javascript:

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

Ceci est cependant valide JSON:

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

Ainsi, vous assurer de toujours renvoyer un objet au premier niveau de la réponse garantit que le JSON n'est pas valide comme Javascript, tout en restant valide.

Comme indiqué par @hvd dans les commentaires, l'objet vide {} est valide en Javascript, et savoir que l'objet est vide peut être en soi 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 client et transfère un code JSON valide. Il n’est toutefois pas certain que des bogues de navigateur antérieurs ou futurs puissent résoudre ce problème. Comme l'a noté @oriadam, il n'est pas clair si les données risquent d'être divulguées lors d'une erreur d'analyse via une gestion d'erreur ou non (par exemple, window.onerror).

Selon Google, la bibliothèque cliente doit prendre en charge la dé-sérialisation automatique et peut être considérée comme plus sûre en ce qui concerne les problèmes de navigateur.

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


Il empêche le détournement de JSON , un problème de sécurité majeur de JSON qui est officiellement fixed dans tous les principaux navigateurs depuis 2011 avec ECMAScript 5.

Exemple élaboré: supposons que Google ait une URL du type 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 situés sur d'autres domaines ne peuvent pas demander à AJAX d'obtenir ces données en raison de la stratégie d'origine identique, mais ils peuvent inclure l'URL via une <script> . L'URL est visitée avec vos cookies. En redéfinissant le constructeur de tableau global ou les méthodes d'accès, elles peuvent avoir une méthode appelée à chaque fois qu'un attribut object (array ou hash) est défini, ce qui leur permet de lire le contenu JSON.

Le while(1); ou &&&BLAH&&& empêche cela: une requête AJAX sur mail.google.com aura un accès complet au contenu du texte et pourra le supprimer. Mais une insertion de balise <script> exécute de manière aveugle le code JavaScript sans aucun traitement, ce qui entraîne une boucle infinie ou une erreur de syntaxe.

Cela ne résout pas le problème de la falsification de requêtes inter-sites .





security