「フレームキラー」コードを使用して、他の人がhttpsページをiframeに埋め込むのを避ける必要がありますか？
さまざまな理由で、httpsがiframeに埋め込まれていることについてさまざまな議論がありました。私はそれをテストし、一方の銀行サイトがiframeをエスケープし、もう一方がiframeに埋め込むことができることを確認しました。
たとえば、Googleはiframeに読み込まれません。 Drupal、cmdとして、CMSにはそのような機能が組み込まれているようには見えません。
フレームキラーコードまたはスクリプトを使用して、サイトへのクリックジャッキングやその他の種類の攻撃を回避することにはマイナス面がありますか？
一般的にこれを行うのは良い習慣ではないでしょうか？
一般的に、それは常に持つ価値があります、あるいはむしろそれは傷つけず、クリックジャッキング攻撃を防ぐことができます。
もちろん、それはあなたの使用シナリオに依存します。たとえば、作成しているコンテンツをiframe（おそらく広告ネットワーク）に表示する必要がある場合は、フレームから抜け出したくないでしょう。
これを実装するためのさまざまなアプローチについて読むのに適したリソースは、 ここ にあります。
もう1つ覚えておくべきことは、それは多少誤った安心感を与える可能性があるということです。クリックジャッキング攻撃と防御策に関しては、いたちごっこゲームです。適切に実装されたクリックジャッキング保護をサイトに追加することは素晴らしいことであり、間違いなく行う価値がありますが、セキュリティに関しては他のすべてのように、目的に適合していることを確認するために定期的に確認する必要があります:)
[〜＃〜]編集[〜＃〜]
クリックジャッキングの防御には、X-Frame-Optionsヘッダーをサポートしない古いブラウザ用のX-Frame-OptionsとビットのJavaScriptの両方を含める必要があることを明確にしたかっただけです。防御のJavaScriptレイヤーにはいくつかの制限がありますが、それらについても このページ で説明されています。
フレームキラーコードまたはスクリプトを使用して、サイトへのクリックジャッキングやその他の種類の攻撃を回避することにはマイナス面がありますか？
フレームキラーには2つの主な欠点があると思います。
- JavaScriptが無効になっている場合（被害者によって、または攻撃者が被害者に対してJavaScriptを実行できた場合）、ページはクリックジャッキングから保護されなくなります。
- ユーザーが自分の電話を使用してWebサイトにアクセスしたい場合はどうなりますか？電話には多くのリソースがなく、通常のマシン（コンピューター）よりも処理が遅いことが知られています重い webpaes（つまりJavaScript/AJAXのロード）
一般的にこれを行うのは良い習慣ではないでしょうか？
X-Frame-Optionsを使用して、サーバー側でのクリックジャッキングのこの問題を解決しないのはなぜですか？