Abusing Open Redirects to get an Account Takeover

It was the end of another semester, and I was really bored, so decided to take a look at the system that my college uses to store and manage all the information about students.

I started to intercept all the requests through Burp Suite proxy, but even after some few hours clicking around on the website, I didn’t find anything that caught my attention.

A few days passed by, and I re-opened the file generated by Burp again, normally, I would just ignore the automatically alerts that burp throws up, since I never found something using those, but when I saw this, I decided to take a look at the request that was performed

https://redacted.redacted.br/aplicacoes/login/login.php?token=53f459561aac1230df1268e9a027be

Instantly when I saw that, my mind thought about an IDOR, but intercepting another token from a secondary account and switching it up, didn’t seem to work, at this point, I remembered that someone mentioned to never burn your open-redirects, because they can be chained to achieve a higher impact, I already had an open-redirect waiting to be used, but it was on another subdomain. After some trial and error, I discovered that this token being passed through a GET request, was weirdly initializing the login flow, which looked like this:

login was started -> token through GET request -> server validates the token, generates the session and return it to the client

My open-redirect luckily was located on the login page, if the user logs in through the “infected link” he could be redirected to anywhere, leaking the initial auth token

https://api.redacted.br/account/?app=system&redirect=https://google.com

Which leads us to an account takeover through a simple open-redirect, we set up a server, set the URL to redirect to our domain, capture the initial token and exchange it using Burp when logging in.