Warum setzen Leute Code wie “throw 1; “und” für (;;); “vor jsons Antworten?

Mögliche Duplikate:
Warum gibt Google während (1) vor? zu ihren JSON Antworten?

Google gibt JSON so zurück:

throw 1;  { foo: bar} 

und Facebooks ajax hat json so:

 for(;;); {"error":0,"errorSummary": ""} 
  • Warum setzen sie Code, der die Ausführung stoppen würde und macht JSON ungültig?
  • Wie analysieren sie es, wenn es ungültig ist und würde abstürzen, wenn Sie versuchten, es auszuwerten?
  • Entfernen sie es nur von der Schnur (scheint teuer)?
  • Gibt es Sicherheitsvorteile?

Als Antwort auf Sicherheitsgründe:

Wenn sich der Scraper in einer anderen Domäne befindet, müsste er ein script Tag verwenden, um die Daten abzurufen, da XHR nicht domänenübergreifend funktioniert. Auch ohne das for(;;); Wie würde der Angreifer die Daten bekommen? Es ist nicht einer Variablen zugewiesen, also wäre es nicht nur Müll gesammelt, weil es keine Verweise darauf gibt?

Im Grunde genommen müssten sie die Daten über die Domäne erhalten

  

Aber auch ohne das vorangestellte Crash-Skript kann der Angreifer keine der Json-Daten verwenden, ohne dass er einer Variablen zugewiesen ist, auf die Sie global zugreifen können (in diesen Fällen ist dies nicht der Fall). Der Crash-Code bewirkt effektiv nichts, denn auch ohne ihn müssen sie serverseitiges Scripting verwenden, um die Daten auf ihrer Site zu verwenden.

Auch ohne das for(;;); Wie würde der Angreifer die Daten bekommen?

Angriffe basieren auf der Änderung des Verhaltens der eingebauten Typen, insbesondere Object und Array , indem sie ihre Konstruktorfunktion oder ihren prototype ändern. Wenn das Ziel-JSON ein Konstrukt {...} oder [...] verwendet, handelt es sich um die eigenen Versionen dieser Objekte des Angreifers mit potenziell unerwartetem Verhalten.

Zum Beispiel können Sie eine Setter-Eigenschaft in Object hacken, die die in Objektliteralen geschriebenen Werte verraten würde:

 Object.prototype.__defineSetter__('x', function(x) { alert('Ha! I steal '+x); }); 

Wenn ein auf einen JSON gerichtet wurde, der diesen Eigenschaftsnamen verwendet:

 {"x": "hello"} 

Der Wert "hello" würde durchgelassen.

Die Art, wie Array- und Objektliterale Setter aufrufen, ist umstritten. Firefox hat das Verhalten in Version 3.5 als Reaktion auf veröffentlichte Angriffe auf hochkarätige Websites entfernt. Zum Zeitpunkt des Schreibens sind Safari (4) und Chrome (5) jedoch immer noch anfällig dafür.

Ein weiterer Angriff, den alle Browser jetzt verbieten, war, Konstruktorfunktionen neu zu definieren:

 Array= function() { alert('I steal '+this); }; [1, 2, 3] 

Und jetzt funktioniert Object.prototype Implementierung von Eigenschaften (basierend auf dem ECMAScript Fifth Edition-Standard und Object.defineProperty ) derzeit nicht mit Object.prototype oder Array.prototype .

Neben dem Schutz vergangener Browser kann es aber auch sein, dass JavaScript-Erweiterungen in Zukunft möglicherweise mehr potenzielle Lücken in ähnlicher Form verursachen. In diesem Fall sollte Spreu auch gegen solche Browser schützen.

Bedenken Sie, dass Sie nach dem Überprüfen Ihres Google Mail-Kontos meine bösartige Seite besuchen:

   

Was jetzt passieren wird ist, dass der Javascript-Code, der von Google kommt – was der Fragesteller für gutartig hielt und sofort aus dem Geltungsbereich ausfällt – tatsächlich auf meiner bösartigen Seite veröffentlicht wird. Angenommen, die URL, die im Skript-Tag angefordert wird, sendet (da Ihr Browser das richtige Cookie anzeigt, wird Google zu Recht davon ausgehen, dass Sie in Ihrem Posteingang angemeldet sind):

 ({ messages: [ { id: 1, subject: 'Super confidential information', message: 'Please keep this to yourself: the password is 42' },{ id: 2, subject: 'Who stole your password?', message: 'Someone knows your password! I told you to keep this information to yourself! And by this information I mean: the password is 42' } ] }) 

Jetzt werde ich eine serialisierte Version dieses Objekts auf meinem bösen Server veröffentlichen. Vielen Dank!

Um dies zu verhindern, müssen Sie Ihre JSON-Antworten auflösen und sie decruftieren, wenn Sie aus derselben Domäne diese Daten manipulieren können. Wenn Ihnen diese Antwort gefällt, akzeptieren Sie bitte die von Bobince gepostete Antwort.

BEARBEITEN

Diese Zeichenfolgen werden gemeinhin als “nicht analysierbare Fehler” bezeichnet und dienen zum Patchen einer Sicherheitslücke, die die JSON-Spezifikation beeinträchtigt. Dieser Angriff ist real und eine Schwachstelle in Google Mail wurde von Jeremiah Grossman entdeckt . Mozilla glaubt auch, dass dies eine Schwachstelle in der JSON-Spezifikation ist und in Firefox 3 gepatcht wurde . Da dieses Problem jedoch immer noch andere Browser betrifft, ist dieser “nicht analysierbare Fehler” erforderlich, da es sich um einen kompatiblen Patch handelt.

Bobices Antwort hat eine technische Erklärung für diesen Angriff und ist korrekt.

Wie analysieren sie es, wenn es ungültig ist und würde abstürzen, wenn Sie versuchten, es auszuwerten?

Es ist eine Eigenschaft, dass es stürzte, wenn Sie versuchten, es zu eval . eval ermöglicht beliebigen JavaScript-Code, der für einen Cross-Site-Scripting-Angriff verwendet werden könnte.

Entfernen sie es nur von der Schnur (scheint teuer)?

Ich stelle mir das vor. Wahrscheinlich so etwas wie:

 function parseJson(json) { json = json.replace("throw 1; ", ""); if (/* regex to validate the JSON */) { return eval(json); } else { throw "XSS"; } } 

Der “Do not Be Evil” -Cruft verhindert, dass Entwickler eval direkt anstelle einer sichereren Alternative verwenden.