web-dev-qa-db-ja.com

親を侵害するためにiframeのXSS脆弱性を使用しますか?

私はparent.comからサードパーティのプラグインをiframeに埋め込むサイトをchild.comと呼びましょう。 child.comにXSSの脆弱性が見つかりました。

child.comの埋め込みページには、同じドメインの別のページにPOSTするフォームが含まれています。フォームを送信することにより、この脆弱性を利用できます。 POSTリクエストをBurpでインターセプトし、それにペイロードを挿入します。その後、ペイロードが実行されます。

私の問題は、ペイロードがchild.comドメインのiframe内で実行されることです。私の目標はparent.comを妥協することです(バグ報奨金を獲得するため)。この脆弱性を使用して何らかの方法でそれを達成することは可能ですか?たとえば、フォームを代わりにparent.comに送信させることはできますか?

5
SecurityQuy

Iframeには、「sandbox」と呼ばれる特別なタグがあり、iframeのコンテンツの処理方法を設定します。そのタグを使用して、iframeが親と対話できるようにアクセス許可を細かく設定できます。通常、iframeは、別のドメインから読み込まれたときに親にどのように影響するかに関してかなり制限がありますが、allow-same-Origin、allow-scripts、allow-top-navigationなどの場合は、ケース固有の場合があります。それを悪用する方法。

[編集] iframe XSS攻撃のほとんどの場合、実際には親Webサイトに任意のコードを挿入することはありません。代わりに、通常は次のいずれかです。

  1. 子Webサイトを制御し、偽のログインフォームのようなものに置き換えて、実際に資格情報をフィッシングしているときに、親Webサイトにログインしてコンテンツにアクセスしていると人々に思わせる。
  2. 個人情報をフィッシングするために実際に使用する、他のプログラマーがサイトに組み込んだ「便利な」サービスを配布します。次に、他のWebサイトに対する人々の信頼を祈り、彼らに有用な情報を提供してもらいます。例:名前、住所、SSNを要求する税額計算機。
  3. Parent.comの代わりに、iframe内にparent.comを含むparents.comという悪質なツインWebサイトを作成して、実際のサイトと同じように動作するようにしますが、Webサイトのバージョンはエンドユーザーの個人情報を収集しています。

したがって、このシナリオを悪用できる最も可能性の高い方法は、フォームをparent.comのログインフォームのようなものに置き換えて、parent.comではなく、実際に制御するものに投稿できる場合です。ユーザーの資格情報を盗みます。

5
Nosajimiki

いいえ、iframeは本質的に制限されているため、これはおそらく不可能です。すべてのiFrameは、ソースとして含まれているサイトへの単純なGETリクエストであり、それを親サイトに埋め込み、さらにそれとの対話を可能にすることを覚えておいてください。子サイト内のPOST-XSS脆弱性について説明しましたが、これもまたGETリクエストのみなので、iframeで自動的にトリガーするのは非常に困難です。

理論的に言えば、子サイトから親サイトにJavaScriptを実行できるブラウザのエクスプロイトを明らかに見つけることができますが、そのようなことは親サイトの賞金よりもはるかに価値があります。さらに、POST-XSSしか持っていないので、それでもおそらくあなたのケースでは機能しません。

IFrameは他のユーザーや私が指摘したように制限されていますが、javascript: URIには例外があることに注意してください。次のようなiframeを例にとります。

<iframe src="javascript:alert(0)"></iframe>

これがWebサイト上にある場合、アラートが表示されるだけでなく、技術的には子サイトがないため、「親サイト」に対するアラートになります。これは興味深い動作であり、iFrameが常に 'restrictive'とは限らないことを証明しています。

1
Cillian Collins