Pourquoi Google ajoute-t-il "while(1);`" à ses réponses JSON (privées) ?
Par exemple, voici une réponse lorsque vous activez et désactivez un calendrier dans [Google Agenda][1] :
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 à faire est de remplacer le while
et vous serez prêt. Je suppose que la prévention de l'eval est destinée à s'assurer que les gens écrivent un code d'analyse JSON sûr.
J'ai vu cela utilisé à quelques autres endroits aussi, mais beaucoup plus avec Google (Mail, Calendar, Contacts, etc.) Assez étrangement, [Google Docs][2] commence par &&&START&&&
à la place, et Google Contacts semble commencer par while(1) ; &&&START&&&
.
Que se passe-t-il ?
[1] : https://calendar.google.com/calendar/about/ [2] : https://www.google.com/docs/about/
Il s'agit de s'assurer qu'un autre site ne puisse pas faire de mauvais tours pour essayer de voler vos données. Par exemple, en [remplaçant le constructeur de tableau][1], puis en incluant cette URL JSON via une balise <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 se bloquera à la place.
En revanche, une requête sur le même site utilisant XHR et un analyseur JSON distinct peut facilement ignorer le préfixe while(1);
.
Il s'agit de rendre difficile pour un tiers d'insérer la réponse JSON dans un document HTML avec la balise <script>
. N'oubliez pas que la balise <script>
est exempte de la [Same Origin Policy][1].
Note : à partir de 2019, beaucoup des anciennes vulnérabilités qui conduisent aux mesures préventives discutées dans cette question ne sont plus un problème dans les navigateurs modernes. Je laisse la réponse ci-dessous comme une curiosité historique, mais vraiment tout le sujet a radicalement changé depuis 2010 ( !!) quand cette question a été posée.
Il l'empêche d'être utilisé comme cible d'une simple balise <script>
. (De cette façon, les personnes mal intentionnées ne peuvent pas simplement placer cette balise script dans leur propre site et compter sur une session active pour récupérer votre contenu.
edit &mdash ; notez le commentaire (et les autres réponses). Le problème est lié à la subversion des fonctionnalités intégrées, en particulier les constructeurs Object
et Array
. Ceux-ci peuvent être modifiés de telle sorte qu'un JSON inoffensif, lorsqu'il est analysé, peut déclencher le code de l'attaquant.