FrameBustingスクリプト

Question

サイトを別のサイトのフレーム内にロードすると、サイトがあらゆる種類の病気にさらされる可能性があることはよく知られています。一般に、保護する機密データがある場合はお勧めできません。
このようにして、FrameBustingスクリプトが作成されました。これは通常、サイトの読み込み中に実行される単純なスクリプトです。フレーム内にある場合は、フレームなしで自分自身をリロードします。
通常、これらの線に沿った単純なもの：

if (top != self) top.location.replace(location);

さて、フォーラムやソーシャルネットワーキングサイトなど、リンクを投稿するのが一般的な公開サイトにいて、それらをフレームに表示する場合は、サイトをフレームバストすることをお勧めします（そこに機密性の高いものがある場合）、ソーシャルネットワーキングの枠外でユーザーにログインさせるなど）。しかし、ユーザーエクスペリエンスを混乱させたり、リンク先のサイトが疑わしいとユーザーに思わせたりしたくない場合もあります。そのため、何が起こっているのかを知らせるポップアップを表示したくなるかもしれません。彼らをさらに怖がらせるかもしれない…。

では、コンテキスト、リスク、結果の全体を考慮し、「セキュリティシアター」を回避することを考慮して、全体的に最善の解決策はどれだと思いますか？

フレーム内にサイトを残す
静かにフレームバスト
何が起こっているかをユーザーに通知するためだけに、ポップアップを提供します
キャンセルするオプションを使用してユーザーにポップアップを提供します

P.S.サイトは [〜＃〜] this [〜＃〜] サイトでしたが、パブリックベータが開始された後、LinkedInの多数のセキュリティ関連グループにサイトを投稿したときにこれを見つけました（なぜそうしないのですか？ ;））、soemの否定的な応答を受け取った...結局、SEはオプション3に進みます-キャンセルするnoオプション付きのポップアップ。クロスポストメタのバグとして ..。

anonymous · Accepted Answer

いい質問です。 FrameBustingは正しく実装するのが難しく、ほとんどの場合、ブラウザの非互換性、バグ、開発者のミスなどの理由で壊れています。

最近、ここで非常によく似た質問に出くわしました： https://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed 。何が起こっているのかについての簡単な説明でユーザーにプロンプトを表示する場所。反対することはできません、より簡単な説明-ユーザーの理解のためにより良いです、ただユーザーのプライバシーに触れる詳細を見逃さないように注意してください。与えられた詳細で、ユーザーは怖がらないように自分で何を考えなければなりません。

そして、OWASPにはこのトピックに関する優れた研究論文があります： http://www.owasp.org/images/0/0e/OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt.pdf

jdm · Answer

私がユーザーとして好む解決策は次のとおりです。サイトをフレーム化できるようにしますが、悪意のあるサイトが害を及ぼさないようにします。フレーム内にいる場合は、別のタブからユーザーのセッションを続行しないでください。この場合、サイトを読み取り専用にすることを検討してください。ユーザーがフレームに再ログインすることを許可する場合は、警告を表示します。もちろん、これはまれなユースケースで実装するための多くの作業であるため、実用的ではない可能性があります。

本当にフレームをバストしたいのなら、邪魔にならない解決策をお勧めします。おそらく X-Frame-Options HTTPヘッダーと組み合わせて、通常のフレームバスティングコードを使用し、ポップアップの代わりにページ上に強調表示されたメモを提供します。

補足：HTMLセキュリティモデルは、あるサイトが他のサイトに対して何かを行うことができないという事実に依存しています。これにより、同一生成元ポリシーが得られます。多くのハッキングは、他のサイトにコードを挿入するなどして、これを回避することに基づいています。クリックジャッキングは関連していますが、コードを使用して他のサイトで機能を実行する代わりに、攻撃ページはユーザーをだましてどこかをクリックさせます。

個人的には、サーバーがブラウザを信頼してスクリプトを制限するHTMLセキュリティモデルには、概念的に欠陥があると思います。私は、コードがユーザーができるほとんどすべてのことを実行できるモデルを好みます。代わりに、代わりにセキュリティトークンに依存します。確かに、攻撃スクリプトは投稿を削除するためのフォームを送信できますが、正しいセッションIDとパスワードがないと無視されます。これにより、マッシュアップ、クライアントのみのコンテンツアグリゲーターなど、はるかに興味深いアプリケーションが可能になります。もちろん、Webをこのようなセキュリティモデルに切り替えるには遅すぎます。

私はアドバイスを動機付けるためにこれを書いています：ブラウザによる分離（フレームバスティングなど）に依存しなくても、すべてのアクションがユーザーによって許可されている安全なサイトを作成することは可能です。セキュリティをフレームなしに依存させないでください。ただし、サイトがフレーム化されていると仮定すると、SOPが侵害され、フレーミングサイトはボタンを押すことができます（ユーザーのインストルメンテーションの有無にかかわらず）。