Warum stellt Google seinen JSON-Antworten while(1); voran?
Warum stellt Google seinen (privaten) JSON-Antworten "while(1)" voran?
Hier ist zum Beispiel eine Antwort während des Ein- und Ausschaltens eines Kalenders in Google Calendar:
while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
['remindOnRespondedEventsOnly','true'],
['hideInvitations_remindOnRespondedEventsOnly','false_true'],
['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]Ich nehme an, dass dies verhindern soll, dass die Leute ein "eval()" darauf anwenden, aber alles, was Sie tun müssen, ist, das "while" zu ersetzen, und dann sind Sie fertig. Ich nehme an, die eval-Verhinderung soll sicherstellen, dass die Leute sicheren JSON-Parsing-Code schreiben.
Ich habe gesehen, dass dies auch an einigen anderen Stellen verwendet wird, aber viel mehr bei Google (Mail, Kalender, Kontakte usw.) Seltsamerweise beginnt Google Docs stattdessen mit &&&START&&&, und Google Contacts scheint mit while(1); &&&START&&& zu beginnen.
Was ist hier los?
3929
3
Damit soll sichergestellt werden, dass eine andere Website keine bösen Tricks anwenden kann, um Ihre Daten zu stehlen. Wenn Sie zum Beispiel den Array-Konstruktor ersetzen und dann diese JSON-URL über ein
<script>-Tag einbinden, könnte eine böswillige Drittanbieterseite die Daten aus der JSON-Antwort stehlen. Wenn Sie ein "while(1)" an den Anfang setzen, bleibt das Skript stattdessen hängen.Eine Anfrage von derselben Seite, die XHR und einen separaten JSON-Parser verwendet, kann dagegen das Präfix "while(1)" problemlos ignorieren.
Dies würde es einem Dritten erschweren, die JSON-Antwort mit dem Tag "<script>" in ein HTML-Dokument einzufügen. Denken Sie daran, dass der
<script>-Tag von der Same Origin Policy ausgenommen ist.Anmerkung: Ab 2019 sind viele der alten Sicherheitslücken, die zu den in dieser Frage erörterten Präventivmaßnahmen führten, in modernen Browsern kein Problem mehr. Ich lasse die Antwort unten als historische Kuriosität stehen, aber tatsächlich hat sich das ganze Thema seit 2010 (!!), als diese Frage gestellt wurde, radikal verändert.
Es verhindert, dass es als Ziel eines einfachen "<script>"-Tags verwendet wird. (Nun, es verhindert es nicht, aber es macht es unangenehm.) Auf diese Weise können Bösewichte dieses Skript-Tag nicht einfach in ihre eigene Website einbauen und sich auf eine aktive Sitzung verlassen, um Ihre Inhalte abrufen zu können.
edit — beachten Sie den Kommentar (und andere Antworten). Das Problem hat mit unterwanderten eingebauten Funktionen zu tun, insbesondere mit den Konstruktoren
ObjectundArray. Diese können so verändert werden, dass ansonsten harmloses JSON, wenn es geparst wird, Angreifercode auslösen kann.