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

Hier ist beispielsweise 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 würde annehmen, dass dies dazu dient, Leute daran zu hindern, etwas zu tun eval(), aber alles, was Sie wirklich tun müssten, ist das zu ersetzen whileund dann wären Sie eingestellt. Ich würde annehmen, dass die Eval-Prävention darin besteht, sicherzustellen, dass die Leute sicheren JSON-Parsing-Code schreiben.

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

Was ist denn hier los?

Es verhindert JSON-Hijacking , ein wichtiges JSON-Sicherheitsproblem, das seit 2011 mit ECMAScript 5 in allen gängigen Browsern offiziell behoben wurde .

Erfundenes Beispiel: Angenommen, Google hat eine URL, mail.google.com/json?action=inboxdie die ersten 50 Nachrichten Ihres Posteingangs im JSON-Format zurückgibt. Böse Websites in anderen Domains können aufgrund der Richtlinie mit demselben Ursprung keine AJAX-Anfragen zum Abrufen dieser Daten stellen, sie können jedoch die URL über ein <script>Tag einschließen . Die URL wird mit Ihren Cookies besucht. Durch Überschreiben der globalen Array-Konstruktor- oder Accessor-Methoden kann eine Methode aufgerufen werden, wenn ein Objektattribut (Array oder Hash) festgelegt wird, sodass sie den JSON-Inhalt lesen können.

Das while(1);oder &&&BLAH&&&verhindert dies: Eine AJAX-Anfrage mail.google.comhat vollen Zugriff auf den Textinhalt und kann ihn entfernen. Beim <script>Einfügen von Tags wird das JavaScript jedoch blind und ohne Verarbeitung ausgeführt, was entweder zu einer Endlosschleife oder zu einem Syntaxfehler führt.

Dies betrifft nicht das Problem der Fälschung von standortübergreifenden Anfragen .

Es verhindert die Offenlegung der Antwort durch JSON-Hijacking.

Theoretisch ist der Inhalt von HTTP-Antworten durch die Richtlinie für denselben Ursprung geschützt: Seiten einer Domäne können keine Informationen von Seiten der anderen Domäne abrufen (sofern dies nicht ausdrücklich gestattet ist).

Ein Angreifer kann in Ihrem Namen Seiten in anderen Domänen anfordern, z. B. mithilfe eines Tags <script src=...>oder <img>, kann jedoch keine Informationen über das Ergebnis (Header, Inhalt) abrufen.

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

Wenn Sie jedoch ein Skript-Tag zum Anfordern von JSON-Inhalten verwenden, wird JSON in der kontrollierten Umgebung eines Angreifers als Javascript ausgeführt. Wenn der Angreifer den Array- oder Objektkonstruktor oder eine andere Methode ersetzen kann, die während der Objektkonstruktion verwendet wird, wird alles im JSON durch den Code des Angreifers geleitet und offengelegt.

Beachten Sie, dass dies zum Zeitpunkt der Ausführung des JSON als Javascript geschieht und nicht zum Zeitpunkt der Analyse.

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 kann den gesamten Inhalt while(1);abrufen, den Inhalt entfernen und den Rest als JSON analysieren.

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

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

In ähnlicher Weise wird durch Hinzufügen ungültiger Token vor dem JSON &&&START&&&sichergestellt, dass er niemals ausgeführt wird.

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

Dies wird OWASPempfohlen , um sich vor JSON-Hijacking zu schützen, und ist weniger aufdringlich.

Ä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ültig JSON:

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

Stellen Sie daher sicher, dass Sie immer ein Objekt auf der obersten Ebene der Antwort zurückgeben. Stellen Sie sicher, dass JSON kein gültiges Javascript ist, während JSON weiterhin gültig ist.

Wie von @hvd in den Kommentaren angegeben, ist das leere Objekt {}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ültiger JSON übertragen wird. Es ist jedoch nicht sicher, ob frühere oder zukünftige Browserfehler dies verhindern könnten. Wie von @oriadam festgestellt, ist unklar, ob bei einem Analysefehler durch eine Fehlerbehandlung Daten verloren gehen könnten oder nicht (z. B. window.onerror).

Der Weg von Google erfordert, dass die Client-Bibliothek die automatische De-Serialisierung unterstützt, und kann als sicherer in Bezug auf Browser-Fehler angesehen werden.

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

Dies soll sicherstellen, dass eine andere Site keine bösen Tricks ausführen kann, um zu versuchen, Ihre Daten zu stehlen. Wenn Sie beispielsweise den Array-Konstruktor ersetzen und diese JSON-URL über ein <script>Tag einfügen, kann eine böswillige Website eines Drittanbieters die Daten aus der JSON-Antwort stehlen. Wenn Sie while(1);am Anfang ein setzen, bleibt das Skript hängen.

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

Dies würde es einem Drittanbieter erschweren, die JSON-Antwort mit dem <script>Tag in ein HTML-Dokument einzufügen . Beachten Sie, dass das <script>Tag von der Richtlinie für denselben Ursprung ausgenommen ist .

Hinweis : Ab 2019 sind viele der alten Sicherheitslücken, die zu den in dieser Frage diskutierten vorbeugenden Maßnahmen führen, in modernen Browsern kein Problem mehr. Ich werde die Antwort unten als historische Kuriosität belassen, aber wirklich hat sich das ganze Thema seit 2010 (!!) radikal verändert, als dies gefragt wurde.

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 Site einfügen und sich auf eine aktive Sitzung verlassen, um das Abrufen Ihrer Inhalte zu ermöglichen.

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

Da das <script>Tag von der Same Origin-Richtlinie ausgenommen ist, die in der Webwelt eine Sicherheitsbedingung darstellt, wird while(1)durch das Hinzufügen zur JSON-Antwort ein Missbrauch im <script>Tag verhindert.

Nach der Authentifizierung kann der JSON-Hijacking-Schutz verschiedene Formen annehmen. Google hängt while (1) an seine JSON-Daten an, sodass das böswillige Skript in eine Endlosschleife eintritt, wenn ein böswilliges Skript es auswertet.

Referenz: Kochbuch zum Testen der Web-Sicherheit: Systematische Techniken zum schnellen Auffinden von Problemen