How I found an XSS vulnerability via using emojis
This is the first writeup in my life so sorry for mistakes.
One day I was working on Swisscom’s bug bounty program and I found a subdomain let’s call now redacted.swisscom.ch
I looked at the parameters they were safe from XSS and removed most of the malicious characters. I thought this is impossible but I kept in mind since the website is using a technology I like.
One day I saw Goat Sniff’s video about one of the Intigriti’s XSS challange (https://www.youtube.com/watch?v=aUsAHb0E7Cg) where he could get an exploit via unicode characters. This was interesting approach for me and I looked back redacted.swisscom.ch to try out.
The site was not vulnerable for this type of XSS but I tried some emojis and the interesting thing was that I’ve got back “ and ‘ characters from the 👔 emoji. Actually the whole string was: d”Y’”
I did a search what this means and suddenly found this github page in one of my searches: https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv
It turned out based on this github page I can also inject < > and as I said previously “ and ‘ characters was also possible.
So after all I crafted this payload:
💋img src=x onerror=alert(document.domain)//💛
I was also interested in what happend on the backend side of this site so I tried to make a simple web page with the same vulnerability. It turned out that the server after removing the malicious characters converted the UTF-8 string from Windows-1252 to UTF-8 (basically the input encoding and the convert from encoding mismatched). Then this does not give a proper < just a weird unicode one: ‹
So they took this output and converted again now from UTF-8 ot ASCII. This normalized the ‹ to < this is how the exploit could work on that system.
Here is the PHP snippet I wrote to test out what happened:
<?php
$str = isset($_GET[“str”]) ? htmlspecialchars($_GET[“str”]) : “”;
$str = iconv(‘Windows-1252’, “UTF-8”, $str);
$str = iconv(‘UTF-8’, “ASCII//TRANSLIT”, $str);
echo “String: “ . $str;
