Utiliser la vulnérabilité XSS dans iframe pour compromettre le parent?
J'ai un site, appelons-le parent.com, qui intègre un plug-in tiers de child.com dans un iframe. J'ai trouvé une vulnérabilité XSS sur child.com.
La page intégrée de child.com contient un formulaire qui POSTE sur une autre page du même domaine. Je peux exploiter la vulnérabilité en soumettant le formulaire. J'intercepte la demande POST avec Burp, et j'y insère ma charge utile. La charge utile est ensuite exécutée.
Mon problème est que la charge utile s'exécute à l'intérieur de l'iframe sur le child.com domaine. Mon objectif est de faire des compromis parent.com (pour gagner une prime de bug). Est-il possible d'utiliser cette vulnérabilité pour y parvenir d'une manière ou d'une autre? Par exemple, puis-je soumettre le formulaire à parent.com au lieu?
Les iframes ont une balise spéciale appelée "sandbox" qui définit comment traiter le contenu de l'iframe. À l'aide de cette balise, vous pouvez définir de manière granulaire les autorisations pour permettre à une iframe d'interagir avec le parent. Normalement, les iframes sont assez restrictifs quant à la façon dont ils peuvent affecter un parent lorsqu'ils sont chargés à partir d'un domaine différent, mais si vous voyez des choses comme: allow-same-Origin, allow-scripts, allow-top-navigation, etc., il peut y avoir un cas spécifique façons de l'exploiter.
[modifier] La plupart des cas d'attaques iframe XSS n'impliquent pas réellement l'injection de code arbitraire dans le site Web parent. Au lieu de cela, ils sont généralement l'un des suivants:
- Vous prenez le contrôle du site Web enfant et le remplacez par quelque chose comme un faux formulaire de connexion pour faire croire aux gens qu'ils se connectent au site Web parent pour accéder au contenu, lorsque vous êtes vraiment en train d'hameçonner leurs informations d'identification.
- Vous distribuez un service "utile" que d'autres programmeurs intègrent dans leurs sites que vous utilisez réellement pour hameçonner des informations privées. Ensuite, vous priez sur la confiance des gens envers ces autres sites Web pour qu'ils vous donnent quelque chose d'utile. Par exemple: une calculatrice de tranche d'imposition qui vous demande votre nom, votre adresse et votre SSN.
- Au lieu de parent.com, vous créez un site Web maléfique appelé parents.com qui contient parent.com à l'intérieur d'un iframe afin qu'il se comporte comme le vrai site, mais votre version du site Web collecte les informations privées de l'utilisateur final.
Ainsi, la façon la plus probable pour vous d'exploiter ce scénario serait de remplacer le formulaire par quelque chose qui ressemble à un formulaire de connexion pour parent.com et de le publier non pas sur parent.com, mais sur quelque chose que vous contrôlez réellement. pour voler les informations d'identification de l'utilisateur.
Non, cela n'est probablement pas possible car les cadres ifram sont de nature restrictive. N'oubliez pas que tout iFrame est, est une simple demande GET au site inclus comme source, puis l'incorporer sur le site parent et permettre une interaction ultérieure avec lui. Vous avez décrit une vulnérabilité POST-XSS au sein du site enfant, qui serait très difficile à déclencher automatiquement dans un iframe car elle l'est encore une fois, seulement une requête GET.
Théoriquement, vous pourriez évidemment trouver un exploit de navigateur qui vous permettrait d'exécuter du javascript d'un site enfant vers un site parent, mais une telle chose est beaucoup plus précieuse que n'importe quelle prime sur le site parent. De plus, cela ne fonctionnerait probablement pas dans votre cas, car encore une fois, vous n'avez que POST-XSS.
Il est utile de noter que bien que les iFrames soient restrictives comme l'ont souligné d'autres utilisateurs et moi-même, il existe une exception pour le javascript: URI. Prenons par exemple un iframe comme ceci:
<iframe src="javascript:alert(0)"></iframe>
Si c'était sur un site Web, non seulement vous obtiendriez une alerte, mais ce serait une alerte sur le "site parent" car techniquement il n'y a pas de site enfant. C'est un comportement intéressant et prouve que les iFrames ne sont pas toujours aussi "restrictives".