クロスドメインのiframeセキュリティ
誰かからのブラウザメッセージを聞いているサイトはどの程度悪用可能ですか？
Iframeの問題が見つかったサイトで作業しています。ケースは、サイトAにサイトBのiframeがあり、サイトAがanywhereからの「メッセージ」をリッスンし、メッセージが届いたときに2つの異なるアクションを実行できる場合です。
- Set document.location = "incoming message data"
- フォームを作成し、action属性値を「incoming message data」に設定し、それをDOMに追加して、フォームを送信します。
これは、サイトEvilを設定し、サイトAのiframeを含め、任意のメッセージの送信を開始できることを意味します。たとえば、「javascript：alert（1）」は、上記のどちらの場合でもiframeコンテキストでjavascriptを実行します。これを私が働いている人々に報告する前に、これが大きな問題になるシナリオが必要です。そして、これがトリッキーになるのはここです。なぜなら、これが重大な問題になるシナリオを実際に思い付くことはできないからです。私の考えは：
- サイトAのコンテキストでJavaScriptを実行できますが、SoPが原因でCookieを取得できません。
- サイトEvilにキーリスナーを設定して、サイトAのiframeにログインを要求する画面を表示させ、サイトAのログインを取得することができます。これには、適切に機能するソーシャルエンジニアリングが必要になります。
しかし、これは私が思いつくことができる最高のものです、それで私の質問は、私は何かを完全に見落としましたか？グーグルで移動しても他のオプションはありません。
編集：
明らかに、これはサイトA（私が働いている）をサイトB（半ば知られている会社ですが）を介してXSSのために開きます。私が作ることについて考えているもう一つのポイントは、一体なぜ誰もがこのように何でもするのでしょうか？フォームを作成して送信し、受信したデータで回答しますか？このようにする理由がわからないのですが、良い人なら誰でもできますか？
EDIT2：
Site Evilにあるiframeを介してSite Aのコンテキストで任意のjavascriptを実行できたとしても、Same Origin Policyをバイパスする方法はないようです。したがって、この「脆弱性」については、ユーザーに任意のリンクをクリックさせることを攻撃者と異なるものにするものは何もありません。
「ハウツー」（エクスプロイト）は提供しませんが、
- Cookieを取得できます（コメントで述べたように、HTTPのみではないもののみ）。
- すべてのCSRF保護をバイパスできます（それらが
Referer/OriginHTTPヘッダーに基づいている場合など）。 - ユーザーに再ログインを求めるポップアップを表示する場合があります（そのため、パスワードを盗みます）。
- 任意のファイル（.exeを含む）をダウンロードすることができ、信頼できるWebサイトからのものであるため、ユーザーは確実にそれを信頼します。
- 衝撃的なイメージなどを含めることで、会社の評判を損なう可能性があります。
- マルウェア/ウイルスをURIに埋め込むことができます（データURI内でbase64化されたEICAR文字列を使用して簡単なエクスプロイトを行います）
これを修正するために提案されたようにしてください：信頼できる受信ドメインのみを受け入れ、それらをフォームなどに入れる前にデータを検証します（本当にドメインやドメインにフォームを送信したくない場合を除いて、メッセージのデータに完全なURIは必要ありません）プロトコル）。
メッセージを送信してそのページ/フレームでJavaScriptを実行できる場合は、Cookieを取得してセッションを確実に乗っ取ることができます。
参照： JavaScriptを介してクロスドメイン投稿リクエストを送信する方法
ここでの最小要件は、管理するサーバーが必要であることです。 AJAXリクエストに対して生成されたレスポンスのAccess-Control-Allow-Originヘッダーを設定できるように。