PostMessage Vulnerabilities
Vulnérabilités PostMessage
Envoyer PostMessage
PostMessage utilise la fonction suivante pour envoyer un message :
Notez que targetOrigin peut être un '*' ou une URL comme https://company.com. Dans le deuxième scénario, le message ne peut être envoyé qu'à ce domaine (même si l'origine de l'objet fenêtre est différente). Si le joker est utilisé, les messages pourraient être envoyés à n'importe quel domaine, et seront envoyés à l'origine de l'objet fenêtre.
Attaquer l'iframe & le joker dans targetOrigin
Comme expliqué dans ce rapport si vous trouvez une page qui peut être iframée (pas de protection X-Frame-Header
) et qui envoie un message sensible via postMessage en utilisant un joker (*), vous pouvez modifier l'origine de l'iframe et exposer le message sensible à un domaine contrôlé par vous.
Notez que si la page peut être iframée mais que le targetOrigin est défini sur une URL et non sur un joker, ce truc ne fonctionnera pas.
Exploitation de addEventListener
addEventListener
est la fonction utilisée par JS pour déclarer la fonction qui s'attend à recevoir des postMessages
.
Un code similaire à celui ci-dessous sera utilisé :
Notez dans ce cas comment la première chose que le code fait est de vérifier l'origine. C'est terriblement important surtout si la page va faire quelque chose de sensible avec les informations reçues (comme changer un mot de passe). Si elle ne vérifie pas l'origine, les attaquants peuvent faire en sorte que les victimes envoient des données arbitraires à ces points de terminaison et changer les mots de passe des victimes (dans cet exemple).
Énumération
Pour trouver des écouteurs d'événements dans la page actuelle, vous pouvez :
Rechercher le code JS pour
window.addEventListener
et$(window).on
(version JQuery)Exécuter dans la console des outils de développement :
getEventListeners(window)
Aller à Éléments --> Écouteurs d'événements dans les outils de développement du navigateur
Utiliser une extension de navigateur comme https://github.com/benso-io/posta ou https://github.com/fransr/postMessage-tracker. Ces extensions de navigateur vont intercepter tous les messages et vous les montrer.
Contournements de vérification de l'origine
L'attribut
event.isTrusted
est considéré comme sécurisé car il renvoieTrue
uniquement pour les événements générés par des actions d'utilisateurs authentiques. Bien qu'il soit difficile à contourner s'il est implémenté correctement, son importance dans les vérifications de sécurité est notable.L'utilisation de
indexOf()
pour la validation de l'origine dans les événements PostMessage peut être sujette à contournement. Un exemple illustrant cette vulnérabilité est :
La méthode
search()
deString.prototype.search()
est destinée aux expressions régulières, pas aux chaînes de caractères. Passer autre chose qu'une expression régulière entraîne une conversion implicite en regex, rendant la méthode potentiellement non sécurisée. Cela est dû au fait qu'en regex, un point (.) agit comme un caractère générique, permettant de contourner la validation avec des domaines spécialement conçus. Par exemple :
La fonction
match()
, similaire àsearch()
, traite les regex. Si le regex est mal structuré, il pourrait être sujet à contournement.La fonction
escapeHtml
est destinée à nettoyer les entrées en échappant les caractères. Cependant, elle ne crée pas un nouvel objet échappé mais écrase les propriétés de l'objet existant. Ce comportement peut être exploité. En particulier, si un objet peut être manipulé de telle sorte que sa propriété contrôlée ne reconnaît pashasOwnProperty
, l'escapeHtml
ne fonctionnera pas comme prévu. Cela est démontré dans les exemples ci-dessous :Échec attendu :
Contournement de l'échappement :
Dans le contexte de cette vulnérabilité, l'objet File
est notablement exploitable en raison de sa propriété name
en lecture seule. Cette propriété, lorsqu'elle est utilisée dans des modèles, n'est pas nettoyée par la fonction escapeHtml
, ce qui entraîne des risques potentiels pour la sécurité.
La propriété
document.domain
en JavaScript peut être définie par un script pour raccourcir le domaine, permettant une application plus souple de la politique de même origine dans le même domaine parent.
Contournement de e.origin == window.origin
Lors de l'intégration d'une page web dans un iframe sandboxé en utilisant %%%%%%, il est crucial de comprendre que l'origine de l'iframe sera définie sur null. Cela est particulièrement important lorsqu'il s'agit des attributs sandbox et de leurs implications sur la sécurité et la fonctionnalité.
En spécifiant allow-popups
dans l'attribut sandbox, toute fenêtre contextuelle ouverte depuis l'iframe hérite des restrictions de sandbox de son parent. Cela signifie que sauf si l'attribut allow-popups-to-escape-sandbox
est également inclus, l'origine de la fenêtre contextuelle est également définie sur null
, correspondant à l'origine de l'iframe.
Par conséquent, lorsqu'une fenêtre contextuelle est ouverte dans ces conditions et qu'un message est envoyé de l'iframe à la fenêtre contextuelle en utilisant postMessage
, les origines de l'envoi et de la réception sont définies sur null
. Cette situation conduit à un scénario où e.origin == window.origin
est évalué à vrai (null == null
), car l'iframe et la fenêtre contextuelle partagent la même valeur d'origine null
.
Pour plus d'informations, lire :
Bypassing SOP with Iframes - 1Contournement de e.source
Il est possible de vérifier si le message provient de la même fenêtre à laquelle le script écoute (particulièrement intéressant pour les Scripts de contenu des extensions de navigateur pour vérifier si le message a été envoyé depuis la même page) :
Vous pouvez forcer e.source
d'un message à être nul en créant un iframe qui envoie le postMessage et est immédiatement supprimé.
Pour plus d'informations, lisez :
Bypassing SOP with Iframes - 2Contournement de l'en-tête X-Frame
Pour effectuer ces attaques, idéalement, vous pourrez placer la page web de la victime à l'intérieur d'un iframe
. Cependant, certains en-têtes comme X-Frame-Header
peuvent empêcher ce comportement.
Dans ces scénarios, vous pouvez toujours utiliser une attaque moins discrète. Vous pouvez ouvrir un nouvel onglet vers l'application web vulnérable et communiquer avec elle :
Vol de message envoyé à l'enfant en bloquant la page principale
Sur la page suivante, vous pouvez voir comment vous pourriez voler des données sensibles postmessage envoyées à un iframe enfant en bloquant la page principale avant d'envoyer les données et en abusant d'un XSS dans l'enfant pour exfiltrer les données avant qu'elles ne soient reçues :
Blocking main page to steal postmessageVol de message en modifiant l'emplacement de l'iframe
Si vous pouvez intégrer une page web sans en-tête X-Frame contenant un autre iframe, vous pouvez modifier l'emplacement de cet iframe enfant, ainsi s'il reçoit un postmessage envoyé en utilisant un joker, un attaquant pourrait modifier l'origine de cet iframe vers une page contrôlée par lui et voler le message :
Steal postmessage modifying iframe locationpostMessage vers Pollution de Prototype et/ou XSS
Dans les scénarios où les données envoyées via postMessage
sont exécutées par JS, vous pouvez intégrer la page et exploiter la pollution de prototype/XSS en envoyant l'exploit via postMessage
.
Un couple de XSS très bien expliqués via postMessage
peuvent être trouvés sur https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html
Exemple d'une exploitation pour abuser de la Pollution de Prototype puis XSS via un postMessage
vers un iframe
:
Pour plus d'informations :
Lien vers la page sur la pollution de prototype
Lien vers la page sur le XSS
Lien vers la page sur la pollution de prototype côté client vers XSS
Références
Pour pratiquer : https://github.com/yavolo/eventlistener-xss-recon
Last updated