iframeを介してXSS脆弱性を悪用する方法
最近、かなり大きなWebサイトにストアドクロスサイトスクリプティングの脆弱性を発見しましたが、それが危険なのか、報告する価値があるのかはわかりません。このWebサイトには、ログインしたユーザーがアクセスできるresourceセクションがあり、自分だけが使用できる特定の個人リソースを投稿できます。リソースを別のユーザーと共有することはできません。また、ポートフォリオページもあり、公開することができます。 2つの脆弱性の可能性を見つけましたが、それらがまったく危険かどうかを確認するように求めています。
Stored XSS：最初の脆弱性には、リンクを投稿できるresourcesページが含まれます。初めてリンクを投稿するときは、サニタイズされており、役立つ情報を入手することはできません。ただし、リンクを編集すると、サニタイズされず、<script>alert(1)</script>または<script>window.location.href="https://google.com"</script>を簡単に挿入できます。
HTMLインジェクション：portfolioと呼ばれる別のページで、ユーザーはポートフォリオを作成してリソースを追加できます。このページには、前のページと同じXSS脆弱性はありません。私の知る限り、JavaScriptを実行することは不可能です。ただし、それにiframeを挿入することは可能です。 iframe srcにjavascriptを含めることはできませんが、srcを私のresourcesページ（保存されたxssの脆弱性がある場所）に誘導して、パブリックプロファイルページでJavaScriptを実行できます。
問題：この脆弱性の問題は、[〜＃〜] i [〜＃〜]ポートフォリオページを表示した場合にのみ機能することです。 iframeのリソースページにはmeしかアクセスできないためです。リソースページのリンクは、表示時に1つのセッションCookie（マイセッションCookie）のみを使用してアクセスできます。 myCookieをiframeに渡して、どのユーザーでもxssの脆弱性を確認できる方法はありますか？ Cookieをhttpヘッダーとして渡すことはできますか（「Set-Cookie」ヘッダーがあります）。 iframeを使用する場合、子供は親のCookieにアクセスできますか？これは脆弱性ですか？それを機能させることはできますか？本当にありがとう！
説明したように、XSSの他のユーザーへの道はわかりません。サイトはおそらくまだ通知されるはずですが、悪用可能性が低いことは明らかです。
ただし、iframeを完全に安全にすることは困難です。 javascript:のソースURIを禁止することは良いスタートですが、data:のURIも同じ起源として扱われるため、ホストウィンドウとやり取りする可能性のある任意の悪意のあるスクリプトを含めることができるため、禁止する必要があります。彼らは、（あなたがすでに試みたように）このコンテキストで有害になるであろう何かをするフレーム可能な同じ起源のページがないことを確認する必要があります。 <object>と<embed>と<svg>を禁止または同様に制限する必要があります。攻撃者がiframeでページ全体を覆ったり、ログインフォームやその他のフィッシングコンテンツを表示したりできないようにする必要があります。攻撃者は、エクスプロイトキット（ページだけでなく、ブラウザの乗っ取りを試みる）をホストしているサイトなど、悪意のある外部サイトをiframeに向けることもできます。ポルノや政治的に過激な画像など、評判が悪い可能性のあるコンテンツから隔離することはほぼ不可能です
さらに、もちろん、iframe（またはその他の埋め込み可能なHTML要素）に、XSSを許可する可能性のある悪意のあるイベントハンドラーまたはインラインスタイルが含まれるリスクもあります。 HTMLを許可することは危険です（もちろん、何かを発見する必要がありますが、これを発見として報告する前に示すことができます）。
これはSelf-XSSと呼ばれます。
これをauthのcsrf脆弱性と組み合わせることができる場合に役立ちます。
- XSSを挿入する
- 制御されたページにアクセスするようにユーザーをトリガーする
- Csrfの脆弱性を使用してこのユーザーをログオフし、アカウントに接続します
- 感染したページにリダイレクトする
または@reedが示唆するように、csrf vulnを使用して被害者アカウントのリンクを編集し、感染したページにリダイレクトします。