Googleが付加する理由 while(1);（プライベート）JSON応答をするのですか？

たとえば、Googleカレンダーでカレンダーをオンまたはオフにしたときの応答は次のとおりです。

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

これは人々がそれをするのを防ぐためeval()だと思いますが、あなたが本当にしなければならないことはwhile、それを交換するだけです。評価の防止は、人々が安全なJSON解析コードを書くようにすることだと思います。

私も他の場所のカップルで使用される、これを見てきましたが、より多くのようにグーグル（メール、カレンダー、連絡先など）とは不思議なことに、Googleドキュメントは、で始まる&&&START&&&代わりに、とGoogleコンタクトを開始するようですwhile(1); &&&START&&&。

何が起きてる？

JSONハイジャックを防ぎます。これは、JSONの主要なセキュリティ問題であり、2011年以降、すべての主要なブラウザで正式に修正されています。 ECMAScript 5を。

不自然な例：Google mail.google.com/json?action=inboxに、受信トレイの最初の50メッセージをJSON形式で返すようなURLがあるとします。他のドメインの悪質なWebサイトは、同じ生成元のポリシーにより、このデータを取得するためにAJAXリクエストを行うことができませんが、<script>タグを介してURLを含めることができます。URLをで訪問しているあなたのクッキー、およびによりグローバル配列コンストラクタまたはアクセサメソッドをオーバーライドし、彼らはいつでもオブジェクト（配列やハッシュ）というメソッドを持つことができる属性は、彼らがJSONの内容を読み取ることができるように、セットです。

while(1);または&&&BLAH&&&防止この：でAJAX要求mail.google.comテキストコンテンツへのフルアクセス権を持つことになりますし、すぐにそれを取り除くことができます。ただし、<script>タグを挿入すると、JavaScriptが何も処理されずに盲目的に実行され、無限ループまたは構文エラーが発生します。

これは、クロスサイトリクエストフォージェリの問題には対応していません。

JSONハイジャックによる応答の開示を防ぎます。

理論的には、HTTP応答のコンテンツは同一生成元ポリシーによって保護されています。あるドメインのページは、他のドメインのページから情報を取得できません（明示的に許可されている場合を除く）。

攻撃者は、例えば、Aを使用することによって、あなたに代わって他のドメイン上のページをリクエストすることができます<script src=...>か<img>タグなどが、結果に関する情報（ヘッダー、コンテンツ）を取得することはできません。

したがって、攻撃者のページにアクセスすると、gmail.comからのメールを読み取ることができません。

スクリプトタグを使用してJSONコンテンツを要求する場合を除いて、JSONは攻撃者の制御された環境でJavaScriptとして実行されます。攻撃者がArrayまたはObjectコンストラクター、またはオブジェクト構築中に使用されるその他のメソッドを置き換えることができる場合、JSON内のすべてのものが攻撃者のコードを通過し、公開されます。

これは、JSONが解析されるときではなく、JavaScriptとして実行されるときに発生することに注意してください。

複数の対策があります。

JSONが実行されないようにする

while(1);JSONデータの前にステートメントを配置することにより、GoogleはJSONデータがJavaScriptとして実行されないようにします。

正当なページのみがコンテンツ全体を取得しwhile(1);、を取り除き、残りをJSONとして解析できます。

以下のようなものがfor(;;);同じ結果で、例えばFacebookので見てきました。

JSONが有効なJavaScriptではないことを確認する

同様に、JSONの前にのよう&&&START&&&に無効なトークンを追加すると、決して実行されないようになります。

常にオブジェクトが外側にあるJSONを返す

これは、JSONハイジャックから保護するためのOWASP推奨される方法であり、それほど邪魔にならない方法です。

以前の対策と同様に、JSONがJavaScriptとして実行されることはありません。

何も囲まれていない場合、有効なJSONオブジェクトはJavaScriptでは無効です。

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

ただし、これは有効なJSONです。

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

したがって、応答の最上位で常にオブジェクトを返すことを確認してください。これにより、JSONは有効でありながら、JSONが有効なJavaScriptではないことを確認できます。

コメントの@hvdで指摘されているように、空のオブジェクト{}は有効なJavascriptであり、オブジェクトが空であることを知ること自体が貴重な情報になる場合があります。

上記の方法の比較

OWASPの方法は、クライアントライブラリを変更する必要がなく、有効なJSONを転送するため、煩わしさが軽減されます。ただし、過去または将来のブラウザのバグがこれを打破できるかどうかは不明です。@oriadamが指摘したように、解析処理でエラー処理（例：window.onerror）によってデータがリークされるかどうかは不明です。

Googleの方法では、自動逆シリアル化をサポートするためにクライアントライブラリが必要であり、ブラウザのバグに対してより安全であると見なすことができます。

どちらの方法でも、開発者が脆弱なJSONを誤って送信しないようにサーバー側の変更が必要です。

これは、他のサイトがデータを盗もうとする悪質なトリックを実行できないようにするためです。たとえば、配列コンストラクターを置き換え、<script>タグを介してこのJSON URLを含めることにより、悪意のあるサードパーティのサイトがJSON応答からデータを盗む可能性があります。while(1);最初にa を置くと、代わりにスクリプトがハングします。

一方、XHRと個別のJSONパーサーを使用する同じサイトのリクエストでは、while(1);プレフィックスを簡単に無視できます。

これにより、サードパーティが<script>タグを使用してJSON応答をHTMLドキュメントに挿入することが困難になります。<script>タグは同一生成元ポリシーから除外されることに注意してください。

注：2019年現在、この質問で説明されている予防策につながる古い脆弱性の多くは、最新のブラウザーでは問題ではなくなりました。以下の答えは歴史的な好奇心として残しておきますが、実際にはトピック全体が2010年（!!）に質問されて以来、根本的に変更されています。

シンプルのターゲットとして使用されるのを防ぎます <script>タグのます。（まあ、それはそれを妨げるものではありませんが、それは不愉快にさせます。）そのようにして、悪意のある人は自分のサイトにそのスクリプトタグを置くだけでなく、あなたのコンテンツをフェッチすることを可能にするためにアクティブなセッションに頼ることはできません。

編集 —コメント（およびその他の回答）を書き留めます。問題は、破壊された組み込み機能、特にObjectおよびArrayコンストラクターに関係しています。それらを変更して、そうでなければ無害なJSONが解析されたときに攻撃者のコードをトリガーする可能性があります。

以来<script>タグはウェブの世界では、セキュリティの必要性である同一生成元ポリシーを免除され、while(1)JSONレスポンス防止に追加するときに、それの誤用<script>タグ。

認証が行われると、JSONハイジャック保護はさまざまな形になります。Googleはwhile（1）をJSONデータに追加するため、悪意のあるスクリプトがそれを評価した場合、悪意のあるスクリプトは無限ループに入ります。

リファレンス：Webセキュリティテストのクックブック：問題をすばやく見つけるための体系的な手法