iframeが危険でセキュリティ上のリスクがあると見なされるのはなぜですか?悪意を持って使用できるケースの例を誰かが説明できますか?
iframeが危険でセキュリティ上のリスクがあると見なされるのはなぜですか?悪意を持って使用できるケースの例を誰かが説明できますか?
回答:
別のドメインのコンテンツを表示すると、基本的にそのドメインを信頼してマルウェアを提供しないことになります。
iframes自体には何も問題はありません。iframeのコンテンツを制御すれば、完全に安全です。
<iframe>
要素を含むドキュメント)に適切なスタイルがあり、iframeに信頼できないコンテンツが含まれていることを示唆している場合、問題はありません。もちろん、ブラウザの実際の脆弱性のモジュロ。つまり、<iframe>
はとほぼ同じくらい安全<a href>
です。
<iframe>
攻撃者が非表示のiframe内のコンテンツを変更できる場合、同じドメインから非表示にすると、セキュリティリスクが発生する可能性があります。これにより、攻撃者は隠さ<iframe>
れた内部のXSS攻撃を、上記の<iframe>
dコンテンツを参照するサイト上の任意のページに拡張できます。詳細については、stackoverflow.com / a / 9428051/334451をご覧ください。
サイトが敵対的なサイトに埋め込まれている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脆弱性を含む(親)ドキュメントの方向に言い換えるべきではありませんか?
<iframe>
、ページで使用する場合、脆弱性をiframe内のコンテンツからホストドキュメントに拡張できます。問題は<iframe>
危険であるということであり、ホストドキュメントにXSSの脆弱性がある場合、<iframe>
要素は本当に必要ありません。
私がクロスドメインのiFrameを想定しているのは、自分で制御すれば、おそらくリスクが低くなるからです。
「危険」と「セキュリティリスク」は、人々がiframeについて言及したときに最初に思い浮かぶものではありませんが、クリックジャッキング攻撃で使用される可能性があります。
iframeはクロスフレームスクリプティングに対しても脆弱です: