Tower of Hanoi

Intigriti - XSS Challenge 1221

by on under Intigriti
2 minute read ·

Let’s start

The challenge comes with an input field and a parameter called “ Stay open “ to avoid repeating an animation, first of all I tried to insert a simple payload like <script>alert(document.domain)</script> to understand where the starting point was.

<h4 id="punchline">Result:  alert(document.domain)
<!-- Referer: -->

From the source, you can see two pieces of information, first of all the content is reflected inside an html comment. This is really important because with a simple payload like --><script>alert(document.domain)</script> we can escape from the comment and execute our xss payload, but there is a problem, you can also see thar the characters < and > are encoded.

At this point I tried to think of various bypasses until I came up with an idea based on a previously played ctf.

Homoglyph characters

Homoglyph are character that look alike but are not the same, so it’s possible to use characters that looks the same but are interpreted differently from the server. this is really important because we can use this type of characters to bypass the control on < and > Here you can see some examples:

Final Payload

To build the final payload I simply used Homoglyph characters regarding the < and the >, in this way I was able to close the html comment and escape in order to execute XSS. To be sure, I url encoded the whole payload:

Just to be clear, clicking the link will not execute the xss, but you will need to enter --﹥﹤script﹥alert(document.domain)﹤/script﹥ inside the input field ( we will see after how to not make this case a self-xss ), and the pop up will appear. In this way i was able to close the html comment in order to get out and execute my payload, as you can see from the source code:

<h4 id="punchline">Result: xss
<!-- Referer:><script>alert(document.domain)</script>

Final Poc

Now that we know how to execute the xss it’s not over, in fact the scenario described is that of a Self-XSS, which is no good. To avoid this problem, I wrote this simple POC:

    <a href="" referrerpolicy="unsafe-url">Click here </a>

The only interesting part is the referrerpolicy="unsafe-url" parameter that is needed to send the origin, path, and query string when performing any request, regardless of security. This means that this policy will leak potentially-private information (in this case our payload) from HTTPS resource URLs to insecure origins, without this parameter it would not be possible to populate the referrer header from an external origin and execute XSS.

The last step is to host our code and insert the payload described above in the url:


Intigriti, Web Exploitation
comments powered by Disqus