可能性のある複製:
なぜ人々はjson応答の前に「throw 1; <dont be evil>」や「for(;;);」のようなコードを置くのですか?
FacebookでAjax呼び出しにこの種の構文が使用されていることがわかりました。応答の最初のfor (;;);
部分で混乱しています。それは何のために使われますか?
これは呼び出しと応答です。
GET http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0
応答:
for (;;);{"t":"continue"}
私は少し遅れて、T.J。基本的に謎を解決しましたが、この特定のトピックに関する優れた論文を共有し、良い例があり、このメカニズムのより深い洞察を提供すると思いました。
これらの無限ループは、「Javascriptハイジャック」に対する対策です。これは、 Jeremiah Grossman によって公開されたGmailへの攻撃で一般の注目を集めた攻撃の一種です。
アイデアはとてもシンプルです。多くのユーザーは、GmailやFacebookに永続的にログインする傾向があります。そのため、あなたはサイトをセットアップし、悪意のあるサイトのJavascriptでオブジェクトまたは配列コンストラクターをオーバーライドします。
function Object() {
//Make an Ajax request to your malicious site exposing the object data
}
次に、そのサイトに<script>
タグを含めます
<script src="http://www.example.com/object.json"></script>
そして最後に、悪意のあるサーバーのログでJSONオブジェクトに関するすべてを読むことができます。
約束どおり、 paper へのリンク。
私はそれがコントロールがある主な理由を疑います。 forcesJSON-Pまたは同様の(script
タグを使用するので、Ajaxを使用してデータを取得するため、そのfor
ループは無限)、したがって Same Origin Policy が開始されます。これにより、API呼び出しを発行できるドキュメントを制御できます。具体的には、同じドキュメントのみそのAPI呼び出しとしてのOrigin、またはFacebookが CORS (CORSをサポートするブラウザー上)経由でアクセスを明確に許可するもの。したがって、ブラウザがSOPを実施するメカニズムを介してデータを要求する必要があり、データをデシリアライズする前にその序文を知って削除する必要があります。
そのため、そのデータへの(有用な)アクセスを制御することが重要です。
Facebookには多数の開発者が多数のプロジェクトで社内で働いており、誰かが小さな間違いを犯すことは非常に一般的です。 HTMLまたはSQLテンプレートに挿入されたデータのエスケープに失敗するほど単純で深刻なものか、eval
(非効率的で間違いなく安全でない場合がある)またはJSON.parse
(準拠しているが「広く知られている」拡張ではない)「既知の良い」JSONデコーダの代わりに、この開発者集団にベストプラクティスを簡単に実施する方法を見つけることが重要です。
この課題に直面するために、Facebookは最近、これらのベストプラクティスを優雅に実施するように設計された内部プロジェクトで「全面的に」出ており、正直に言うと、この特定のケースに本当に理にかなっている唯一の説明はそれだけです:解析は、コアライブラリ内の単一の実装を通過する必要があり、それを実施する最良の方法は、すべてのAPIレスポンスがfor(;;);
を自動的に前面に付加することです。
そうすることで、開発者は「怠け者」になることはできません。彼らはeval()
を使用する場合、即時に気付くでしょう。 。
提供されている他の回答はすべて、次の2つのカテゴリのいずれかに分類されるようです。
最初のカテゴリーの人々は、攻撃者が何らかの方法でそれをサポートしていないAPIに「JSONPを使用して」リクエストを行うことができるという考えに依存しています。 JSONPは、サーバーとクライアントの両方でサポートする必要があるプロトコルです。結果がローカル関数に渡されるように、サーバーはmyFunction({"t":"continue"})
に類似した何かを返す必要があります。偶然「JSONPを使用」することはできません。
2番目のカテゴリのユーザーは、非常に現実的な脆弱性を挙げています。これは、APIのタグを介したクロスサイトリクエストフォージェリを許可するしない JSONP(このような)を使用し、 JSONハイジャック」。これは、ラッピング関数なしでサーバーから返される情報にアクセスできるようにするArray/Objectコンストラクターを変更することで実行されます。
ただし、この場合は単に不可能です。動作する理由は、ベア配列(有名なGmailの例など、多くのJSON APIの1つの結果)が有効な式ステートメントであるためです。裸のオブジェクト。
実際、JSONで定義されたオブジェクトの構文(この例のようにフィールド名を引用符で囲む)はブロックの構文と競合するため、スクリプトの最上位で使用することはできません。
js> {"t":"continue"}
typein:2: SyntaxError: invalid label:
typein:2: {"t":"continue"}
typein:2: ....^
この例がObject()コンストラクターの再マッピングによって悪用されるためには、代わりにAPIが括弧のセット内のオブジェクトを返し、有効なJavaScript(ただし有効なJSONではない)にする必要があります。
js> ({"t":"continue"})
[object Object]
さて、それはcouldこのfor(;;);
プレフィックストリックはこの例に「偶然」現れているだけで、実際には配列を返している他の内部Facebook APIによって返されています。しかし、この場合、for(;;);
がこの特定のスニペットに表示される理由の「本当の」原因になるので、実際に注意する必要があります。
for(;;);
は無限ループです(必要に応じて、ChromeのJavaScriptコンソールを使用してタブでそのコードを実行し、タスクマネージャーのCPU使用率がブラウザーがタブを強制終了するまで屋根を通過するのを確認できます)。
そのため、eval
または返されたデータを実行する他の手法を使用して、応答を解析しようとするユーザーをいらいらさせるためにそこに置かれているのではないかと思います。
さらに説明すると、以前はJavaScriptのeval()
関数を使用してJSON形式のデータを少し解析するのが一般的でした。
var parsedJson = eval('(' + jsonString + ')')
;
...これは安全ではないと見なされますが、何らかの理由でJSON形式のデータにJSON形式のデータの代わりに(またはJSON形式のデータに加えて)実行可能なJavaScriptコードが含まれている場合、そのコードはeval()
によって実行されます。これは、信頼されていないサーバーと通信している場合、または信頼されているサーバーをだれかが侵害した場合、ページで任意のコードを実行できることを意味します。
このため、eval()
のようなものを使用してJSON形式のデータを解析することは一般的に嫌われ、Facebook JSONのfor(;;);
ステートメントは、人々がそのようにデータを解析することを防ぎます。試みる人は誰でも無限ループに陥ります。つまり、Facebookは、人々がAPIを使用して、ベクターとして使用するためにFacebook APIをハイジャックしようとする将来のエクスプロイトに対して脆弱にならないように、そのAPIを使用するように強制しているようです。
これはCSRF攻撃を防ぐためのハックのように見えます。オブジェクト作成にフックするブラウザ固有の方法があるため、悪意のあるWebサイトは最初にそれを使用し、次に次のことを行う可能性があります。
<script src="http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0" />
JSONの前に無限ループがない場合、JSONはeval()
edとしてjavascriptとして作成できるため、オブジェクトが作成されます。フックはそれを検出し、オブジェクトメンバーを嗅ぎます。
これで、Facebookにログインしているときにブラウザーからそのサイトにアクセスすると、あたかも自分のようにデータを取得し、AJAXやjavascriptポストなどを介して独自のサーバーに送り返すことができます。 。