You are on page 1of 3

How I found an XSS vulnerability via using emojis | by Patrik Fabian | ... https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-usi...

Open in app Get started

Patrik Fabian Follow

Aug 13 · 2 min read · Listen

Save

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.

1 of 3 17-08-2022, 14:17
How I found an XSS vulnerability via using emojis | by Patrik Fabian | ... https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-usi...

So after all I crafted this payload:


Open in app Get started

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

320 4

2 of 3 17-08-2022, 14:17
How I found an XSS vulnerability via using emojis | by Patrik Fabian | ... https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-usi...

Open in app Get started

About Help Terms Privacy

Get the Medium app

3 of 3 17-08-2022, 14:17

You might also like