it-swarm.com.de

Warum stellt Google while (1) voran? auf ihre JSON-Antworten?

Warum stellt Google den (privaten) JSON-Antworten while(1); voran?

Beispiel: Hier ist eine Antwort zum Ein- und Ausschalten eines Kalenders in Google Kalender :

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

Ich würde davon ausgehen, dass dies dazu dient, die Leute daran zu hindern, eine eval() auszuführen, aber alles, was Sie wirklich tun müssen, ist, die while zu ersetzen, und dann würden Sie festgelegt. Ich würde davon ausgehen, dass die Eval Prevention darin besteht, sicherzustellen, dass die Leute sicheren JSON-Parsing-Code schreiben.

Ich habe dies auch an einigen anderen Orten gesehen, aber viel mehr bei Google (Mail, Kalender, Kontakte usw.) Seltsamerweise Google Text & Tabellen beginnt mit &&&START&&& stattdessen und Google-Kontakte scheinen mit while(1); &&&START&&& zu beginnen.

Was ist hier los?

3892
Jess

Es verhindert JSON-Hijacking , ein wichtiges JSON-Sicherheitsproblem, das formal behoben in allen wichtigen Browsern seit 2011 mit ECMAScript 5 vorliegt.

Erfundenes Beispiel: Angenommen, Google hat eine URL wie mail.google.com/json?action=inbox, die die ersten 50 Nachrichten Ihres Posteingangs im JSON-Format zurückgibt. Schlechte Websites in anderen Domains können aufgrund der gleichen Origin-Richtlinie keine AJAX -Anforderungen zum Abrufen dieser Daten stellen, sie können jedoch die URL über ein <script> -Tag einschließen. Die URL wird mit Ihren Cookies besucht, und durch Überschreiben des globalen Array-Konstruktors oder der Zugriffsmethoden können sie jederzeit eine Methode aufrufen Es wird ein Objektattribut (Array oder Hash) festgelegt, mit dem der JSON-Inhalt gelesen werden kann.

Die while(1); oder &&&BLAH&&& verhindern dies: Eine AJAX Anfrage bei mail.google.com hat vollen Zugriff auf den Textinhalt und kann ihn entfernen. Durch das Einfügen eines <script> -Tags wird das JavaScript jedoch blind ausgeführt, ohne dass eine Verarbeitung erforderlich ist. Dies führt entweder zu einer Endlosschleife oder zu einem Syntaxfehler.

Hiermit wird das Problem Cross-Site Request Forgery nicht behoben.

4143
rjh

Es verhindert die Offenlegung der Antwort durch JSON-Hijacking.

Theoretisch wird der Inhalt von HTTP-Antworten durch die Richtlinie "Gleicher Ursprung" geschützt: Seiten einer Domain können keine Informationen von Seiten der anderen Domain abrufen (es sei denn, dies ist ausdrücklich gestattet).

Ein Angreifer kann in Ihrem Namen Seiten in anderen Domänen anfordern, z. durch Verwendung eines <script src=...> - oder <img> -Tags, aber es können keine Informationen über das Ergebnis (Überschriften, Inhalte) abgerufen werden.

Wenn Sie also die Seite eines Angreifers besuchen, konnte dieser Ihre E-Mail von gmail.com nicht lesen.

Mit der Ausnahme, dass bei Verwendung eines Script-Tags zum Anfordern von JSON-Inhalten JSON in einer vom Angreifer kontrollierten Umgebung als Javascript ausgeführt wird. Wenn der Angreifer den Array- oder Object-Konstruktor oder eine andere Methode ersetzen kann, die während der Objektkonstruktion verwendet wird, wird alles in der JSON-Datei durch den Code des Angreifers geleitet und offengelegt.

Beachten Sie, dass dies zu dem Zeitpunkt geschieht, an dem JSON als Javascript ausgeführt wird, und nicht zu dem Zeitpunkt, an dem es analysiert wird.

Es gibt mehrere Gegenmaßnahmen:

Stellen Sie sicher, dass JSON niemals ausgeführt wird

Durch Platzieren einer while(1); -Anweisung vor den JSON-Daten stellt Google sicher, dass die JSON-Daten niemals als Javascript ausgeführt werden.

Nur eine legitime Seite könnte tatsächlich den gesamten Inhalt abrufen, die Funktion while(1); entfernen und den Rest als JSON analysieren.

Dinge wie for(;;); wurden zum Beispiel bei Facebook gesehen, mit den gleichen Ergebnissen.

Stellen Sie sicher, dass JSON kein gültiges Javascript hat

Ebenso wird durch das Hinzufügen ungültiger Token vor dem JSON, wie z. B. &&&START&&&, sichergestellt, dass dieser niemals ausgeführt wird.

Geben Sie JSON immer mit einem Objekt an der Außenseite zurück

Dies ist OWASP empfohlene Methode zum Schutz vor JSON-Hijacking und die weniger aufdringliche.

Ähnlich wie bei den vorherigen Gegenmaßnahmen wird sichergestellt, dass der JSON niemals als Javascript ausgeführt wird.

Ein gültiges JSON-Objekt ist in Javascript nicht gültig, wenn es von nichts eingeschlossen ist:

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

Dies ist jedoch gültiger JSON:

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

Wenn Sie also sicherstellen, dass Sie immer ein Objekt auf der obersten Ebene der Antwort zurückgeben, stellen Sie sicher, dass JSON kein gültiges Javascript hat, während JSON noch gültig ist.

Wie @hvd in den Kommentaren feststellt, ist das leere Objekt {} ein gültiges Javascript, und das Wissen, dass das Objekt leer ist, kann selbst eine wertvolle Information sein.

Vergleich der obigen Methoden

Der OWASP-Weg ist weniger aufdringlich, da keine Änderungen an der Clientbibliothek erforderlich sind und gültiges JSON übertragen wird. Es ist jedoch unsicher, ob vergangene oder zukünftige Browser-Fehler dies verhindern könnten. Wie von @oriadam bemerkt, ist es unklar, ob bei einem Analysefehler durch eine Fehlerbehandlung Daten verloren gehen könnten oder nicht (z. B. window.onerror).

Die Vorgehensweise von Google erfordert eine Client-Bibliothek, damit die automatische Deserialisierung unterstützt wird, und kann im Hinblick auf Browser-Fehler als sicherer angesehen werden.

Beide Methoden erfordern serverseitige Änderungen, um zu verhindern, dass Entwickler versehentlich anfällige JSON-Dateien senden.

533
Arnaud Le Blanc

Damit soll sichergestellt werden, dass keine andere Website böse Tricks ausführen kann, um zu versuchen, Ihre Daten zu stehlen. Durch Ersetzen des Array-Konstruktors und anschließendes Einschließen dieser JSON-URL über ein <script> -Tag könnte eine böswillige Site eines Drittanbieters die Daten aus der JSON-Antwort stehlen. Wenn Sie am Anfang ein while(1); setzen, bleibt das Skript hängen.

Andererseits kann eine Anforderung mit derselben Site, die XHR und einen separaten JSON-Parser verwendet, das Präfix while(1); leicht ignorieren.

358
bdonlan

Dies würde es einem Drittanbieter erschweren, die JSON-Antwort in ein HTML-Dokument mit dem Tag <script> einzufügen. Denken Sie daran, dass das <script> -Tag von der Same Origin Policy ausgenommen ist.

106
Daniel Vassallo

Anmerkung: Ab 2019 sind viele der alten Sicherheitslücken, die zu den in dieser Frage behandelten vorbeugenden Maßnahmen führten, in modernen Browsern kein Problem mehr. Ich werde die Antwort unten als historische Kuriosität belassen, aber das ganze Thema hat sich seit 2010 (!!), als dies gefragt wurde, grundlegend geä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 das Skript-Tag nicht einfach in ihre eigene Site einfügen und sich auf eine aktive Sitzung verlassen, um den Abruf Ihrer Inhalte zu ermöglichen.

edit - notiere den Kommentar (und andere Antworten). Das Problem hat mit unterwanderten eingebauten Einrichtungen zu tun, insbesondere den Konstruktoren Object und Array. Diese können so geändert werden, dass ansonsten harmloses JSON beim Analysieren Angreifercode auslösen kann.

78
Pointy

Da das Tag <script> von der Richtlinie "Same Origin Policy" ausgenommen ist, die in der Web-Welt eine Sicherheitsanforderung darstellt, verhindert while(1) beim Hinzufügen zur JSON-Antwort die missbräuchliche Verwendung im Tag <script>.

10
kg11