Bypassing SOP with Iframes - 1
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
このチャレンジは、NDevTKとTerjanqによって作成され、XSSを悪用する必要があります。
主な問題は、メインページがDomPurifyを使用してdata.body
を送信するため、独自のHTMLデータをそのコードに送信するには、e.origin !== window.origin
をバイパスする必要があることです。
提案されている解決策を見てみましょう。
//example.org
がサンドボックス化されたiframeに埋め込まれると、ページのオリジンは**null
になります。つまり、window.origin === null
です。したがって、<iframe sandbox="allow-scripts" src="https://so-xss.terjanq.me/iframe.php">
を介してiframeを埋め込むだけで、null
オリジンを強制**できます。
ページが埋め込み可能であれば、その方法でその保護をバイパスできます(クッキーもSameSite=None
に設定する必要があるかもしれません)。
あまり知られていない事実は、サンドボックス値allow-popups
が設定されている場合、開かれたポップアップはallow-popups-to-escape-sandbox
が設定されていない限り、すべてのサンドボックス属性を継承することです。
したがって、nullオリジンからポップアップを開くと、ポップアップ内の**window.origin
もnull
**になります。
したがって、このチャレンジのために、iframeを作成し、脆弱なXSSコードハンドラー(/iframe.php
)を持つページにポップアップを開くことができます。window.origin === e.origin
のため、両方がnull
であるため、XSSを悪用するペイロードを送信することが可能です。
そのペイロードは識別子を取得し、XSSをトップページ(ポップアップを開いたページ)に戻します。そのページは、脆弱な/iframe.php
にロケーションを変更します。識別子が知られているため、条件window.origin === e.origin
が満たされないことは問題ではありません(オリジンはオリジンが**null
のiframeからのポップアップ**であることを思い出してください)なぜなら、data.identifier === identifier
だからです。次に、XSSが再びトリガーされます。今度は正しいオリジンで。
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)