私のサイトがモデルといくつかのビュー(クライアント側、ブラウザー内)を提供し、サードパーティのサイトが独自のビューを追加する拡張可能なプラットフォームを作成しようとしています。ここでの目標は、私のモデルのみがサーバーにHTTPリクエストを行い、サードパーティのビューがプラットフォームに対してのみAPI呼び出しを行うことです(必要に応じて、コールバックすることもできますが、触れないでください)。 APIを通じて明示的に公開されていないもの)。
提案されたソリューションは、 見えないpostMessage のみを使用してそれらと通信する各サードパーティ拡張機能のiframe(Edit:当然のことながら、適切な「ビュー」になるためには、表示する必要があります、しかし代わりに、それは単に「コントローラー」の役割を持ち、ビジュアルコンポーネントのレンダリングをメインページに委任することができます。これはコードを適切に「サンドボックス化」するでしょうか?私はそれを想定しています:
Window.alert
(またはより悪い:Window.Prompt
)、console.log
または他の「グローバル」なものにアクセスします。これは私がこれまでに特定したより悪い問題であり、それを防ぐ方法をまだ考えることができません。これらの仮定は正しいですか、他に知っておくべきことはありますか?ユーザーの側からある程度の信頼が必要になります(つまり、私のサイトが拡張機能を推奨しているかどうかに関係なく、各ユーザーは拡張機能を自分の都合に合わせて選択し、最終的に彼の選択の結果をもたらすことができるはずです)。それらのリスクを軽減するために可能な限りのことをしたいと思います。
更新:コメント投稿者からの質問に基づいて、質問を少し明確にしたいと思います。広告、分析、ソーシャルネットワークとの相互作用など、サードパーティのスクリプトをページに含める理由はたくさんあります。ただし、これはセキュリティ上の問題ですが、実際、これはAdBlockまたはNoScriptを使用する理由の1つです(したがって、ブラウザでコードを実行できるドメイン)。通常、サイトは、スクリプトが含まれているサードパーティを信頼しますが、常にではありません(たとえば、Facebookアプリケーションは誰でも作成できますが、Facebookページ内で実行されます)。iframeがサードパーティの「分離」に使用されているのを見ましたパーティーの内容。
ブラウザーでのクロスサイト通信の1つのオプションは、postMessageを使用して2つのタブ(またはウィンドウ)を開いてメッセージを交換することですが、1つのページでよりシームレスなエクスペリエンスを提供できます。 iframe(可視または不可視)を使用することの完全な影響、および信頼できないコンテンツのサンドボックス化におけるその実行可能性は、この質問における私の主な関心事であり、IMHOはより広い対象者にも適用できます(上記の段落を参照)。
私の特定のケースでは、埋め込まれたコンテンツが親サイトになりすますことを避け(上記の4番目の箇条書きの説明を参照)、ユーザーを一般的な限り他の迷惑から保護します。各ユーザーは自分の拡張機能を選択することができますが、最終的に結果に責任がありますが、私は手の届く範囲にある既知の問題を軽減します(そして、そうでないものについてユーザーを教育します)。
サードパーティのコンテンツをiframeに読み込むつもりですが、サードパーティのコンテンツはメインコンテンツと同じドメインからホストされますか、それとも別のドメインから提供されますか?
サードパーティのコンテンツがメインページと同じドメインでホストされている場合、いいえ、あなたのアプローチは完全に安全ではありません。 iframe内のコンテンツは、同じオリジン(ほぼ同じドメイン)から提供されている場合、メインページへの完全なスクリプトアクセス権を持っています。同じ起源のポリシーについてお読みください。
より合理的なアプローチは、メインページとは異なるドメインでサードパーティ拡張コンテンツをホストすることです。これを実行すると、はい、あなたのアプローチは妥当なセキュリティを提供します。拡張機能のコンテンツはサンドボックス化され、メインページを混乱させることはできません(ほとんどの場合)。以下に示すように、いくつかのリスクが残っています。
Iframeのサードパーティコンテンツは、メインページをナビゲートできます(例:window.location
またはtop.location
)。したがって、サードパーティのコンテンツは、ページ全体をサードパーティが選択したコンテンツで置き換えます。これにより、フィッシング攻撃やスプーフィング攻撃が可能になる可能性があります。ブラウザーのアドレスバーのURLが変わるため、警告ユーザーはこのような攻撃に気づくかもしれませんが、一部のユーザーは気付かないかもしれません。
サードパーティの拡張機能は、独自のiframe内に不快なコンテンツ(たとえば、ポルノ、広告など)を引き続きロードできます。
サードパーティの拡張機能は、ユーザーにドライブバイダウンロード攻撃を仕掛けようとする可能性があります。ユーザーが脆弱なブラウザを使用している場合、攻撃に感染する可能性があります(もちろん、悪意のあるサイトにアクセスしている場合はこれに該当する可能性があります。リスクを増大させるiframeについては何もありません-それがなくなることはありません。 、どちらか)。
サードパーティのコンテンツは映画や音声を再生する可能性があり、ユーザーを煩わせる可能性があります。
サードパーティの拡張機能により、メインページにクリックジャッキング攻撃が仕掛けられる可能性があります。 (iframeは非表示になるとおっしゃっていますが、これがクリックジャッキングに対する堅牢な防御であることを確認するために必要な具体的な方法は正確にはわかりません。多くのブラウザーの癖がそこにあります。)
サイトで強力なCSRF防御を使用することが重要です。それ以外の場合、サードパーティのコンテンツはCSRF攻撃を開始するのに最適な位置になります。
これらのリスクの多くは比較的軽微であり、ほとんどの場合は許容できるかもしれませんが、私はあなたと他の人のためにそれらを概説したいと思いました。
別のアプローチは、システムを Javascriptサンドボックス に使用することです(これらは「仮想iframe」を構築する方法と考えることもできます)。例: Caja 、 [〜#〜] ses [〜#〜] 、 ADsafe 、 [〜#〜] fbjs [〜#〜] 、およびMicrosoftのWebサンドボックス。
サンドボックス化されたiframes も確認できますが、すべてのブラウザーでサポートされているわけではないため、このメカニズムをセキュリティに頼ることはできません(残念ながら)。
関連項目 ウェブサイトに広告を掲載する前に知っておくべきリスクは? 、 iframesを使用したセキュリティの問題 、 悪意のあるコードがないかJavaScriptをスキャンする方法は? 。
また、same-Originポリシーおよびその種のトピックに関連するブラウザの癖に関する詳細については、 ブラウザセキュリティハンドブック を強くお勧めします。
このデモ にアクセスすると、URLを変更するよりも、コードがフレーム内でそれ自体を検出する(変更してそのページを検出できる)ことがわかります。親サイトになりすます可能性のあるURL。 (sidenote私はgoogleとyahooが空白になったことに気付き、そのbcのヘッダーが「X-Frame-Options:SAMEORIGIN」を送信すると信じています)
ウィンドウの制御についてはあまり知りません。そのため、別のウィンドウがサイトを閉じ、別のウィンドウを起動して偽装する可能性があります。しかし、DOMとJavaScriptの観点からは、ユーザーのコードを実行せずにコードを実行してもユーザーに害を及ぼすことはありません。ただし、ユーザーをだますことは別の話です。