iframeが危険でセキュリティ上のリスクがあると見なされるのはなぜですか?


124

iframeが危険でセキュリティ上のリスクがあると見なされるのはなぜですか?悪意を持って使用できるケースの例を誰かが説明できますか?


5
それは古い妻の話のように聞こえます。ブラウザウィンドウは、基本的に1つの大きなiframeです。
Bill Criswell、2011

1
すでにstackoverflowについて質問されました
Samich

1
@Samich —いいえ、それはベストプラクティスに関するものであり、具体的にはセキュリティの問題ではありません(そして、私が考えることができる唯一のセキュリティの問題は、iframeを使用するサードパーティから発生します)
Quentin

それほどのセキュリティは、そのベストプラクティスとはみなされないよう、以下を参照してくださいstackoverflow.com/questions/1081315/why-developers-hate-iframes divをすべて、人々はまた、テーブルを設計したときに彼らはより多くの人気があったが、アイフレームの必要性を排除します。
RandomUs1r 2014年

おかしなことに、約10年後にポップアップした記事は、フォームを含むものをiframeに入れて、サードパーティのすべてのJavaScriptなどから分離することが、フォームが収集されないようにするために必要になる可能性があることを示唆しています。 hackernoon.com/…– GordonM 2018
1

回答:


83

別のドメインのコンテンツを表示すると、基本的にそのドメインを信頼してマルウェアを提供しないことになります。

iframes自体には何も問題はありません。iframeのコンテンツを制御すれば、完全に安全です。


19
別のドメインなどのコンテンツにリンクするとすぐに…これに固有のiframeはありません。
クエンティン

5
正しく実装されたブラウザー(別名ユーザーエージェント)では、iframeの内容がiframeの外に漏れることはありません。ホストドキュメント(<iframe>要素を含むドキュメント)に適切なスタイルがあり、iframeに信頼できないコンテンツが含まれていることを示唆している場合、問題はありません。もちろん、ブラウザの実際の脆弱性のモジュロ。つまり、<iframe>はとほぼ同じくらい安全<a href>です。
Mikko Rantalainen

2
同じドメインに属する非表示のiframeはどうですか?これは完全に安全ですか?
Ciaran Gallagher

2
<iframe>攻撃者が非表示のiframe内のコンテンツを変更できる場合、同じドメインから非表示にすると、セキュリティリスクが発生する可能性があります。これにより、攻撃者は隠さ<iframe>れた内部のXSS攻撃を、上記の<iframe>dコンテンツを参照するサイト上の任意のページに拡張できます。詳細については、stackoverflow.com / a / 9428051/334451をご覧ください。
ミッコランタライネン2014年

興味深いことに、iFrameは実際には逆のケースからの保護に役立つ場合があります。サイトにサードパーティのスクリプトがたくさんある場合は、フォームからスクリプトを分離する必要があります。これを行うための1つの提案された方法は、サードパーティのJavaScriptを使用せずにフォームを独自の最小ページに配置し、ホストページのiframeに表示することでした。 hackernoon.com/…– GordonM 2018
1

140

サイトが敵対的なサイトに埋め込まれているIFRAME場合、この要素はセキュリティリスクになる可能性がありますIFRAME。詳細については、Googleの「クリックジャッキング」。次の場合は問題ではないことに注意してくださいあなたが使用し<iframe>たりありません。この攻撃からの唯一の真の保護は、HTTPヘッダーを追加X-Frame-Options: DENYし、ブラウザーがその仕事を知っていることを期待することです。

加えて、 サイトのいずれかのページに、悪用可能なXSS脆弱性が含まれている場合 IFRAME要素がセキュリティリスクになる可能性があります。この場合、攻撃者はXSS攻撃を同じドメイン内の任意のページに拡大し、<iframe>XSS脆弱性のあるページ上の内にロードするように仕向けることができます。これは、同じオリジン(同じドメイン)のコンテンツが親コンテンツのDOMにアクセスすることが許可されているためです(実際には、「ホスト」ドキュメントでJavaScriptを実行します)。この攻撃からの唯一の実際の保護方法は、HTTPヘッダーを追加するX-Frame-Options: DENYか、ユーザーが送信したすべてのデータを常に正しくエンコードすることです(つまり、サイトにXSSの脆弱性がない-言うより簡単です)。

それが問題の技術的な側面です。 さらに、ユーザーインターフェイスの問題があります。ユーザーがリンクをクリックしてもURLバーが変更されないことを信頼するようにユーザーに教える場合(たとえば、サイトで実際のコンテンツすべてを含む大きなiframeを使用している場合)、実際のセキュリティの場合でもユーザーは将来何も気付かないでしょう。脆弱性。たとえば、サイト内にXSSの脆弱性があり、攻撃者がiframe内の悪意のあるソースからコンテンツをロードできる可能性があります。URLバーは以前の動作と同じように見え(変更されることはない)、コンテンツはユーザーの資格情報を要求する悪意のあるドメインからのものであるにもかかわらず「有効」に見えるため、誰も違いを見分けることができません。

<iframe>サイトで要素を使用することが危険であり、セキュリティリスクを引き起こすと誰かが主張した場合、彼はその<iframe>要素の機能を理解していないか<iframe>、ブラウザに関連する脆弱性の可能性について話しています。<iframe src="...">タグのセキュリティは、ブラウザの脆弱性と同じ<img src="..."かそれ以上<a href="...">である。そして、適切な脆弱性がある場合は<iframe>、を使用しなくてもトリガーされる可能性があります。<img><a>要素ため、この問題について検討する価値はありません。

ただし、のコンテンツは<iframe>デフォルトでトップレベルのナビゲーションを開始できることに注意してください。つまり、内のコンテンツは、<iframe>現在のページの場所にあるリンクを自動的に開くことができます(新しい場所はアドレスバーに表示されます)。それを回避する唯一の方法は、sandbox値のない属性を追加することですallow-top-navigation。たとえば、<iframe sandbox="allow-forms allow-scripts" ...>。残念ながら、サンドボックスは常にすべてのプラグインを無効にします。たとえば、すべてのYoutubeコンテンツを表示するにはFlashプレーヤーが必要なため、Youtubeコンテンツをサンドボックス化することはできません。プラグインの使用とトップレベルのナビゲーションの禁止を同時にサポートするブラウザーはありません。

注意X-Frame-Options: DENYも(また、「として知られているコンテンツのクロスオリジンを読み取ることができ、パフォーマンスサイドチャネル攻撃のレンダリングから保護ピクセル完璧なタイミング攻撃を」)。


いいですが"This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."、iframeの(子)ドキュメントに対するXSS脆弱性を含む(親)ドキュメントの方向に言い換えるべきではありませんか?
Shuzheng

@Shuzheng脆弱性は両方の方向に進み<iframe>、ページで使用する場合、脆弱性をiframe内のコンテンツからホストドキュメントに拡張できます。問題は<iframe>危険であるということであり、ホストドキュメントにXSSの脆弱性がある場合、<iframe>要素は本当に必要ありません。
ミッコランタライネン

13

私がクロスドメインのiFrameを想定しているのは、自分で制御すれば、おそらくリスクが低くなるからです。

  • クリックジャッキングサイトがiframeとして含まれている場合、は問題です
  • 侵害されたiFrameが悪意のあるコンテンツを表示する可能性があります(iFrameが広告の代わりにログインボックスを表示することを想像してください)
  • 含まれているiframeは、アラートやプロンプトなどの特定のJS呼び出しを行う可能性があり、ユーザーを困らせる可能性があります
  • 含まれているiframeはlocation.href経由でリダイレクトできます(そうです、3pフレームが顧客をbankofamerica.comからbankofamerica.fake.comにリダイレクトするとします)
  • 3pフレーム内のマルウェア(java / flash / activeX)がユーザーに感染する可能性があります


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.