Frage Warum gibt Google während (1) vor? zu ihren JSON Antworten?


Warum gibt Google vor? while(1); zu ihren (privaten) JSON-Antworten?

Zum Beispiel, hier ist eine Antwort beim 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 gehe davon aus, dass dies verhindern soll, dass Menschen an einer Krankheit leiden eval() darauf, aber alles, was Sie wirklich tun müssten, ist das Ersetzen der while und dann würdest du festgelegt werden. Ich würde annehmen, dass die Eval-Vorbeugung dafür sorgt, dass Leute sicheren JSON-Parsing-Code schreiben.

Ich habe gesehen, dass dies auch an einigen anderen Orten verwendet wurde, aber noch viel mehr mit Google (Mail, Kalender, Kontakte usw.). Seltsamerweise Google Dokumente beginnt mit &&&START&&& Stattdessen scheint Google Contams damit zu beginnen while(1); &&&START&&&.

Was ist denn hier los?


3483
2018-04-19 18:00


Ursprung


Antworten:


Es verhindert JSON Hijacking.

Contrived Beispiel: Sagen Google hat eine URL wie mail.google.com/json?action=inbox Das gibt die ersten 50 Nachrichten Ihres Posteingangs im JSON-Format zurück. Schlechte Websites in anderen Domains können AJAX-Anfragen aufgrund der Richtlinie für denselben Ursprung nicht stellen, um diese Daten zu erhalten, aber sie können die URL über einen Link einschließen <script> Etikett. Die URL wird mit besucht Ihre Cookies und durch Überschreiben der globalen Array-Konstruktor- oder Accessor-Methoden Sie können eine Methode aufrufen, die immer dann aufgerufen wird, wenn ein Objekt (Array oder Hash) -Attribut gesetzt ist, damit sie den JSON-Inhalt lesen können.

Das while(1); oder &&&BLAH&&& verhindert dies: eine AJAX-Anfrage bei mail.google.com hat vollen Zugriff auf den Textinhalt und kann es entfernen. Aber a <script> Die Tag-Einfügung führt das JavaScript blind ohne jegliche Verarbeitung aus, was entweder zu einer Endlosschleife oder zu einem Syntaxfehler führt.

Dies betrifft nicht das Problem von Cross-Site-Anfrage Fälschung.


3760
2018-04-19 18:11



Es verhindert die Offenlegung der Antwort durch JSON Hijacking.

Theoretisch ist der Inhalt von HTTP-Antworten durch die gleiche Ursprungsrichtlinie geschützt: Seiten aus einer Domäne können keine Informationen von Seiten einer anderen Domäne abrufen (sofern nicht ausdrücklich erlaubt).

Ein Angreifer kann in Ihrem Namen Seiten auf anderen Domains anfordern, z. mit a <script src=...> oder <img>Tag, aber es kann keine Informationen über das Ergebnis (Header, Inhalt) erhalten.

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

Abgesehen davon, dass bei der Verwendung eines Script-Tags zum Anfordern von JSON-Inhalten das JSON als Javascript in einer kontrollierten Umgebung eines Angreifers ausgeführt wird. Wenn der Angreifer den Array- oder Object-Konstruktor oder eine andere Methode, die während der Objektkonstruktion verwendet wird, ersetzen kann, würde alles im JSON den Code des Angreifers passieren und offengelegt werden.

Beachten Sie, dass dies zu dem Zeitpunkt geschieht, zu dem der JSON als Javascript ausgeführt wird und nicht zum Zeitpunkt der Analyse.

Es gibt mehrere Gegenmaßnahmen:

Sicherstellen, dass JSON niemals ausgeführt wird

Indem Sie a while(1); Statement 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 bekommen, strippen die while(1);, und den Rest als JSON analysieren.

Dinge wie for(;;); wurden zum Beispiel bei Facebook mit denselben Ergebnissen gesehen.

Stellen Sie sicher, dass das JSON kein gültiges Javascript ist

Ähnliches gilt auch für das Hinzufügen ungültiger Tokens vor dem JSON &&&START&&&, stellt sicher, dass es nie ausgeführt wird.

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

Das ist OWASP empfohlene Art und Weise vor JSON Hijacking zu schützen, und ist weniger aufdringlich.

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

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

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

Dies ist jedoch gültig 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 das JSON kein gültiges JavaScript ist, während JSON immer noch gültig ist.

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

Vergleich der obigen Methoden

Der OWASP-Weg ist weniger aufdringlich, da er keine Änderungen an der Client-Bibliothek benötigt und gültige JSON-Daten überträgt. Es ist nicht sicher, ob vergangene oder zukünftige Browser-Bugs dies jedoch besiegen könnten. Wie von @oriadam festgestellt wurde, ist es unklar, ob Daten in einem Parse-Fehler durch eine Fehlerbehandlung oder nicht (z. B. Fensterfehler) geleakt werden könnten.

Googles Art erfordert eine Client-Bibliothek, um die automatische Deserialisierung zu unterstützen, und kann in Bezug auf Browserfehler als sicherer angesehen werden.

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


442
2018-02-02 12:09



Dadurch wird sichergestellt, dass eine andere Website keine üblen Tricks ausführen kann, um zu versuchen, Ihre Daten zu stehlen. Zum Beispiel durch Ersetzen des Array-Konstruktors, dann einschließlich dieser JSON-URL über a <script> Eine bösartige Website eines Drittanbieters könnte die Daten aus der JSON-Antwort stehlen. Indem man a while(1); Am Anfang hängt das Skript stattdessen.

Eine siteseitige Anforderung, die XHR und einen separaten JSON-Parser verwendet, kann andererseits die while(1); Präfix.


343
2018-05-16 02:08



Das würde es einem Dritten erschweren, die JSON-Antwort in ein HTML-Dokument mit einzutragen <script> Etikett. Denken Sie daran, dass die <script> Das Tag ist von der Gleiche Ursprungsrichtlinie.


97
2018-04-19 18:04



Es verhindert, dass es als Ziel eines Einfachen verwendet wird <script> Etikett. (Nun, es verhindert es nicht, aber es macht es unangenehm.) Auf diese Weise können Bösewichte das Skript-Tag nicht einfach auf ihrer eigenen Seite platzieren und sich auf eine aktive Sitzung verlassen, um es zu ermöglichen, Ihren Inhalt zu holen.

bearbeiten - Notiere den Kommentar (und andere Antworten). Das Problem hat mit untergrabenen eingebauten Einrichtungen zu tun, speziell der Object und Array Konstruktoren. Diese können so verändert werden, dass ansonsten harmlose JSONs, wenn sie analysiert werden, einen Angreifercode auslösen könnten.


65
2018-04-19 18:02



Seit der <script> tag ist von der gleichen Ursprungsrichtlinie ausgenommen, die eine Sicherheitsnotwendigkeit in der Netzwelt ist, während (1), wenn es der JSON Antwort hinzugefügt wird, Missbrauch davon in der verhindert <script>Etikett.


3
2017-08-18 04:14