Cross-Site Scripting (XSS) is one of the most common vulnerabilities found across a web penetration testing. However, depending on the injection point, a character limitation problem could be found. In this post, unicode compatibility is going to be taken to exploit some XSS vulnerabilities.
In Unicode equivalence some sequences of code points represent essentially the same character. This feature was introduced in the standard to allow compatibility with preexisting standard character sets. Unicode provides two ways of handling that: canonical equivalence and compatibility.
Canonical equivalence: Code point sequences are assumed to have the same appearance and meaning when printed or displayed. For example,
Compatible equivalence: Code point sequences are assumed to have possibly distinct appearances, but the same meaning in some contexts. For example
ﬀcharacter has the equivalent to
20 length limitation problem
Browsers perform unicode compatibility with some characters, let’s see an example. Supose we have this payload:
ﬀ characters is only one character but when browsers interpret it, it will be expanded as
ff two characters. This open the door to buy larger domains, in a cheaper way.
- ﬀ expands to
- ℠ expands to
- ㏛ expands to
- ﬆ expands to
- ㎭ expands to
- ℡ expands to
More of these characters can be found here.
To check in which characters are decomposed check here:
Then, lets register a domain a
telsr.pw for example. It costs only
Our final payload will look like this:
Observe how the normalization is performed and our registered endpoint is trying to be reached with a payload of 20 characters instead of 23 characters thanks of unicode compatibility.
Therefore, a domain is registered and a payload is trying to reach that domain, however it has not executed anything yet.
One thing came into my mind, let’s perform a DNS Redirect, it will work as follows:
- 1. XSS is triggered and browser tries to load the content of to
- 2. DNS redirects to
xsshunter.comto trigger the XSS execution.
- 3. Win
But there is a problem, if the connection goes over HTTPS and we trigger a script with
If the comunication goes over HTTP this is not a problem, but it is not the common scenario.
This was solved doing the following:
- 1. Buy a hosting to that domain, the cheapest one
$1.44/mo. In my case was using namecheap.com.
- 2. Set up a HTTPS certificate, it is free the first year.
- 3. In your control panel, go to the redirection form and perform a redirection to the place you have the
- 4. Redirection is performed and execution triggered.