Googlewhile(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（メール、カレンダー、連絡先など）ではさらに多く使用されています。不思議なことに、Googleドキュメントは&&&START&&&代わりに始まり、Googleコンタクトはで始まるようwhile(1); &&&START&&&です。

何が起きてる？

これにより、JSONハイジャックが防止されます。これは、2011年以降ECMAScript5ですべての主要なブラウザーで正式に修正された主要なJSONセキュリティの問題です。

不自然な例：Googlemail.google.com/json?action=inboxに、受信トレイの最初の50メッセージをJSON形式で返すようなURLがあるとします。他のドメインの邪悪なウェブサイトは、同一生成元ポリシーのため、このデータを取得するためにAJAXリクエストを行うことはできませんが、<script>タグを介してURLを含めることができます。URLはCookieを使用してアクセスされ、グローバル配列コンストラクターまたはアクセサーメソッドをオーバーライドすることで、オブジェクト（配列またはハッシュ）属性が設定されるたびに呼び出されるメソッドを持つことができ、JSONコンテンツを読み取ることができます。

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

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

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

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

攻撃者は、<script src=...>または<img>タグを使用するなどして、他のドメインのページを要求できますが、結果に関する情報（ヘッダー、コンテンツ）を取得することはできません。

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

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

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

複数の対策があります：

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

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

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

for(;;);たとえば、Facebookでも同様のことが見られ、同じ結果が得られています。

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

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

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

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

前の対策と同様に、JSONがJavaScriptとして実行されないようにします。

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

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

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

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

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

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

上記の方法の比較

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

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

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

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

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

これは、サードパーティがJSON応答を<script>タグ付きのHTMLドキュメントに挿入することを困難にするためです。<script>タグは同一生成元ポリシーから免除されていることに注意してください。

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

単純な<script>タグのターゲットとして使用されるのを防ぎます。（まあ、それはそれを防ぐことはできませんが、それは不快になります。）そうすれば、悪者はそのスクリプトタグを自分のサイトに置いて、アクティブなセッションに依存してコンテンツをフェッチできるようにすることはできません。

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

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

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

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