3

この質問は以前に質問され、正しく回答されましたが、解決策が投稿されていないようです。

サイトにiframeがあり、それらが別のドメインのフレームに囲まれないようにしたい場合、単純なフレームバスティングは役に立ちません。

<script>if (top != self) top.location = location</script>

ただし、他のドメインへのクロスフレームスクリプトは例外を生成するはずなので、次のようなものはiframe内でうまく機能するようです。

<script>
try {
  if (window.document.domain != top.document.domain) {   // throws exception
    throw "You naughty puppy!"; // Should not ever get here, right?
  }
}
catch () {
  top.location = "/error/naughtypuppy";
}
</script>

上記ifは、iframeのクロスドメインフレーミングを防ぐのに十分なはずです。false例外を返すかスローするだけでよいので、とにかくスクリプトがthrowブラウザのステートメントに到達する可能性はありますか？

これは、他のドメインからのフレーミングのみを防ぐのに十分でしょうか？

<script>
try {
  var bogus = top.document.domain;
}
catch () {
  top.location = "/error/naughtypuppy";
}
</script>

編集：同様の解決策がここで示唆されていますが、フレームバスティングコードを含めるために親フレームに依存することはありません。iframeがクロスドメインであるかどうかを検出し、それを無効にします。基本的に、「例外が発生した場合は、他のフレームにアクセスしてバストを試行する」と同じソリューションです。

4

2 に答える 2

2

そのコードは、「onbeforeunload」機能を利用する攻撃の形式に対して脆弱です。親（悪）ページは、間隔ハンドラー（ドメインの違いにより、コードに対して無防備です）と「onbeforeunload」ハンドラーを設定します。2番目のハンドラーは、ウィンドウが「攻撃を受けている」という事実を記録するためにいくつかのグローバル変数（これも無防備）を更新し、次にインターバルタイマー（ブラウザーが外側のウィンドウを完了する前にアクティブになることができるように十分に高速に実行される）を更新します正当なURLへの更新）がポップアップ表示され、no-op204応答を返す攻撃者が制御するURLを指すように更新されます。window.locationブラウザはHTTPリクエストを忘れ、代わりにインターバルハンドラによって開始された新しいトランザクションからウィンドウを「更新」します。

これが古いSOの質問です：フレームバスターバスター...必要なバスターコード

于 2010-11-15T17:08:18.353 に答える
1

まだフレームがあるサイトがあり、今のところ削除できません。これは私が見つけた最良の解決策でした：

<style>html { display:none }</style>
<script>
if (self == top) {
  document.documentElement.style.display = 'block';
} else {
  top.location = self.location;
}
</script>

このリンクから：XFS 101-cross-frame-scripting-explained

からのプレゼンテーションに基づく：OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt

これは、より更新されたOWaspクリックジャッキングページです。

于 2014-10-02T21:21:03.980 に答える