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

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 davon ausgehen, dass dies die Leute daran hindern soll, eine zu tun eval() darauf, aber alles, was Sie wirklich tun müssten, ist das zu ersetzen while und dann wärst du eingestellt. Ich würde davon ausgehen, dass die Eval-Prävention sicherstellen soll, dass die Leute sicheren JSON-Parsing-Code schreiben.

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

Was ist denn hier los?

Es verhindert JSON-Hijackingein wichtiges JSON-Sicherheitsproblem, das formal ist Fest in allen gängigen Browsern seit 2011 mit ECMAScript 5.

Ausgedachtes Beispiel: Nehmen wir an, Google hat eine URL wie mail.google.com/json?action=inbox die die ersten 50 Nachrichten Ihres Posteingangs im JSON-Format zurückgibt. Böse Websites auf anderen Domains können aufgrund der Same-Origin-Policy keine AJAX-Anfragen stellen, um diese Daten abzurufen, aber sie können die URL über a <script> Schild. Die URL wird mit besucht dein Kekse und durch Überschreiben des globalen Array-Konstruktors oder der Accessor-Methoden Sie können eine Methode aufrufen lassen, wenn ein Objektattribut (Array oder Hash) festgelegt wird, sodass sie den JSON-Inhalt lesen können.

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

Damit wird das Problem nicht angesprochen Cross-Site-Anfragefälschung.

Es verhindert die Offenlegung der Antwort durch JSON-Hijacking.

Theoretisch ist der Inhalt von HTTP-Antworten durch die Same Origin Policy geschützt: Seiten einer Domain können keine Informationen von Seiten der anderen Domain erhalten (sofern nicht ausdrücklich erlaubt).

Ein Angreifer kann in Ihrem Namen Seiten auf anderen Domains anfordern, z. B. durch Verwendung von 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, kann dieser Ihre E-Mail von gmail.com nicht lesen.

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

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

Es gibt mehrere Gegenmaßnahmen:

Stellen Sie sicher, dass JSON niemals ausgeführt wird

Durch das Setzen von a while(1); -Anweisung vor den JSON-Daten stellt Google sicher, dass die JSON-Daten niemals als JavaScript ausgeführt werden.

Nur eine seriöse Seite könnte tatsächlich den ganzen Inhalt bekommen, der streift while(1);und analysieren Sie den Rest als JSON.

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

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

Ebenso das Hinzufügen ungültiger Token vor dem JSON, wie z &&&START&&&stellt sicher, dass es nie ausgeführt wird.

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

Das ist OWASP empfohlener Weg zum Schutz vor JSON-Hijacking und ist die weniger aufdringliche.

Ähnlich wie bei den vorherigen Gegenmaßnahmen stellt es sicher, dass 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, da die { } wird als Codeblock interpretiert:

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

Dies ist jedoch gültiges 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 ist, aber dennoch gültiges JSON ist.

Wie von @hvd in den Kommentaren angemerkt, das leere Objekt {} ist gültiges JavaScript, und zu wissen, dass das Objekt leer ist, kann selbst eine wertvolle Information sein.

Vergleich der obigen Methoden

Der OWASP-Weg ist weniger aufdringlich, da er keine Änderungen an der Clientbibliothek erfordert und gültiges JSON überträgt. Es ist jedoch nicht sicher, ob vergangene oder zukünftige Browserfehler dies verhindern könnten. Wie von @oriadam angemerkt, ist unklar, ob Daten bei einem Parsing-Fehler durch eine Fehlerbehandlung durchgesickert sein könnten oder nicht (z. B. window.onerror).

Der Weg von Google benötigt eine Client-Bibliothek, um die automatische Deserialisierung zu unterstützen, und kann als sicherer in Bezug auf Browserfehler angesehen werden.

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

Damit soll sichergestellt werden, dass eine andere Website keine fiesen Tricks anwenden kann, um zu versuchen, Ihre Daten zu stehlen. Zum Beispiel durch Ersetzen des Array-Konstruktorsdann fügen Sie diese JSON-URL über a ein <script> Tag könnte eine böswillige Drittanbieter-Website die Daten aus der JSON-Antwort stehlen. Durch das Setzen von a while(1); am Anfang bleibt das Skript stattdessen hängen.

Eine Same-Site-Anfrage mit XHR und einem separaten JSON-Parser hingegen kann das problemlos ignorieren while(1); Präfix.

Das würde es einem Drittanbieter erschweren, die JSON-Antwort in ein HTML-Dokument mit einzufügen <script> Schild. Denken Sie daran, dass die <script> -Tag ist von der ausgenommen Gleiche Ursprungsrichtlinie.

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

Es verhindert, dass es als Ziel eines einfachen verwendet wird <script> Schild. (Nun, es verhindert es nicht, aber es macht es unangenehm.) Auf diese Weise können Bösewichte nicht einfach dieses Skript-Tag in ihre eigene Site einfügen und sich auf eine aktive Sitzung verlassen, um es zu ermöglichen, Ihre Inhalte abzurufen.

bearbeiten — Beachten Sie den Kommentar (und andere Antworten). Das Problem hat mit untergrabenen eingebauten Einrichtungen zu tun, insbesondere mit der Object und Array Konstrukteure. Diese können so geändert werden, dass ansonsten harmloses JSON beim Analysieren Angreifercode auslösen könnte.

Seit der <script> -Tag ist von der Same Origin Policy ausgenommen, die eine Sicherheitsanforderung in der Webwelt ist, while(1) wenn es der JSON-Antwort hinzugefügt wird, verhindert es einen Missbrauch in der <script> Schild.

Da dies ein stark frequentierter Beitrag ist, hoffe ich, hier eine etwas unbestimmtere Antwort auf die ursprüngliche Frage zu geben und somit weitere Hintergrundinformationen zu einem JSON-Hijacking-Angriff und seinen Folgen zu liefern

JSON Hijacking ist, wie der Name schon sagt, ein Angriff, der Cross-Site Request Forgery ähnelt, bei dem ein Angreifer auf domänenübergreifende sensible JSON-Daten von Anwendungen zugreifen kann, die sensible Daten als Array-Literale an GET-Anfragen zurückgeben. Ein Beispiel für einen JSON-Aufruf, der ein Array-Literal zurückgibt, ist unten dargestellt:

[{"id":"1001","ccnum":"4111111111111111","balance":"2345.15"}, 
{"id":"1002","ccnum":"5555555555554444","balance":"10345.00"}, 
{"id":"1003","ccnum":"5105105105105100","balance":"6250.50"}]

Dieser Angriff kann in 3 Hauptschritten erreicht werden:

Schritt 1: Bringen Sie einen authentifizierten Benutzer dazu, eine bösartige Seite zu besuchen. Schritt 2: Die bösartige Seite versucht, auf vertrauliche Daten aus der Anwendung zuzugreifen, bei der der Benutzer angemeldet ist. Dies kann durch Einbetten eines Skript-Tags in eine HTML-Seite erfolgen, da die Richtlinie des gleichen Ursprungs nicht für Skript-Tags gilt.

<script src="http://<jsonsite>/json_server.php"></script>

Der Browser sendet eine GET-Anforderung an json_server.php und alle Authentifizierungs-Cookies des Benutzers werden zusammen mit der Anfrage gesendet. Schritt 3: Zu diesem Zeitpunkt hat die bösartige Website, während sie das Skript ausgeführt hat, keinen Zugriff auf sensible Daten. Der Zugriff auf die Daten kann durch Verwendung eines Objektprototypsetzers erreicht werden. Im folgenden Code wird eine Objektprototyp-Eigenschaft an die definierte Funktion gebunden, wenn versucht wird, die “ccnum” Eigentum.

Object.prototype.__defineSetter__('ccnum',function(obj){
    secrets =secrets.concat(" ", obj);
});

Zu diesem Zeitpunkt hat die bösartige Website erfolgreich die sensiblen Finanzdaten entführt (ccnum) ist zurückgekommen byjson_server.php
JSON

Es ist zu beachten, dass nicht alle Browser diese Methode unterstützen; der Machbarkeitsnachweis wurde auf Firefox 3.x durchgeführt. Diese Methode wurde nun als veraltet markiert und durch die ersetzt useObject.defineProperty Es gibt auch eine Variation dieses Angriffs, die auf allen Browsern funktionieren sollte, in denen JavaScript mit vollem Namen (z pi=3.14159) wird anstelle eines JSON-Arrays zurückgegeben.

Es gibt mehrere Möglichkeiten, JSON-Hijacking zu verhindern:

• Da SCRIPT-Tags nur HTTP-GET-Anforderungen generieren können, geben Sie nur JSON-Objekte an POST-Anforderungen zurück.

• Verhindern Sie, dass der Webbrowser das JSON-Objekt als gültigen JavaScript-Code interpretiert.

• Implementieren Sie den Schutz vor standortübergreifender Anforderungsfälschung, indem Sie verlangen, dass für alle JSON-Anforderungen ein vordefinierter Zufallswert erforderlich ist.

also wie man sieht While(1) fällt unter die letzte Option. In den einfachsten Worten, while(1) ist eine Endlosschleife, die ausgeführt wird, bis explizit eine break-Anweisung ausgegeben wird. Und damit das, was man als Sperre für den anzuwendenden Schlüssel bezeichnen würde (google break-Anweisung). Daher wird ein JSON-Hijacking, bei dem der Hacker keinen Schlüssel hat, konsequent abgewiesen. Wenn Sie den JSON-Block mit einem Parser lesen, wird die While(1)-Schleife ignoriert.

Also abschließend die while(1) Schleife kann einfacher als a visualisiert werden einfach Break-Statement-Chiffre, mit der Google den Datenfluss kontrollieren kann.

Das Schlüsselwort in dieser Aussage ist jedoch das Wort “einfach‘. Die Verwendung von authentifizierten Endlosschleifen wurde im Laufe der Jahre glücklicherweise aus der grundlegenden Praxis entfernt seit 2010 aufgrund seiner absoluten Dezimierung der CPU-Auslastung, wenn isoliert (und die Tatsache, dass sich das Internet davon entfernt hat, grobe „Schnelllösungen“ durchzusetzen). Heute sind stattdessen in die Codebasis vorbeugende Maßnahmen eingebettet und das System ist weder entscheidend noch effektiv mehr. (Ein Teil davon ist die Abkehr vom JSON-Hijacking hin zu fruchtbareren Data-Farming-Techniken, auf die ich derzeit nicht eingehen werde.)