2017-03-23 8 views
2

以下に概要を説明するアプリケーションがあります。 UIは安全なドメインhttps://aaa.comから提供され、同じドメインのスクリプトをホストします。IFRAMEを介したpostMessageによる安全なチャネル

クライアントサイトhttps://client.comをIFRAMEにロードします。このサイトは信頼できるものではなく、悪質なXSSが含まれている可能性があります。一般に、コード品質はアプリケーションよりも低い可能性があります。

サイトでは、2番目のドメインhttps://bbb.comから信頼できる別のスクリプトが読み込まれます。このスクリプトは、必要に応じてhttps://aaa.comから作成することもできます。 aaaとbbbスクリプトはaaa.comからREST APIを呼び出し、そのためのセキュリティトークンが必要です。セキュリティトークンは、ドメインaaaの一番上のウィンドウからUIにログインして取得します。

我々はIFRAMEに私たちのスクリプトの民間閉鎖にブラウザウィンドウ内のプライベート閉鎖(scriptA.js)からセキュリティトークンを渡すために安全なチャネルを確立する必要があります(scriptB.js)

クライアントとしてサイトが異なるドメインである場合は、スクリプトの通信にpostMessage APIを使用する必要があります。理想的には、「こんにちは、私はscriptBです。この鍵で暗号化されたトークン(その単一のイベントに対して生成された非対称暗号化公開鍵)を私に送信し、悪意のあるXSSが読むことができない暗号化された鍵をscriptAに送ります"

しかし、悪意のあるXSSは、同じドメインに座っているのでscriptBであることを偽って、そのメッセージを自分の鍵で早く送信し、応答からトークンを聞くことができます。

問題は、client.comやその他のドメインからロードされたXSSからではなく、https://bbb.comからロードされたスクリプトから送信されたscriptAで要求メッセージを確認できるかどうか、またはその他の安全な通信方法scriptAからscriptBにトークンを安全に渡すために使用できます。

提案がありますか?

Scheme

答えて

0

潜在的な訪問者に知らせるだけです。このような問題を解決する手段はありませんでした。そのような通信手段を確保する手段にはCORSがあります.CORSは許可のためにCookieを使用する場合にのみ使用できます。通信にクッキーが含まれていない場合、攻撃者サーバーはフォワードプロキシとして使用され、含まれているCORS測定値をバイパスすることができます。

postMessageにスクリプトのURL(ホスティングウィンドウではない)が含まれていない限り、そのような通信を保護し、XSSがターゲットスクリプトを模倣するのを防ぐ方法はないようです。

我々は最終的にそれを解く方法は、以下の仮定に基づいていた:トークンが確保された

  • 場合であっても、悪質なXSSはまだキーボードとマウスのイベントを発することができるし、この方法は、コンテンツを操作しますそのような視点では多方向のユーザーができます。このため

、我々は(確保されている)のScriptaで親ウィンドウのコンテキストから呼び出されたサーバーのAPIによって生成された別のトークンへの請求として、以前より一般的なトークンをラップするために選択され、制限されています可能なユーザアクションは、ユーザアクションによって実行可能なアクションのみに限られる。このトークンは、scriptBが呼び出すサーバーで検証されます。

この結果、XSSがメッセージからトークンを盗んだとしても、キーボードイベントやマウスイベントを偽ってユーザーアクションをシミュレートする以上のことはできません。それに加えて、トークンは時間制限があるため、XSSがトークンを盗むとしても、後で外部から同じデータを操作するために、トークンを保存することはできません。

最終的にクライアント側のセキュリティバグは、インフラストラクチャ全体ではなく、自分の単一のページにしか妥協しません。

関連する問題