Account takeover through a linked login
Consumer internet
A consumer platform let people sign in with a third-party account and message each other privately. We were asked whether the linked login could be turned against the account, and whether private messages stayed private.
Web & API penetration test, Consumer social platform, severity CRITICAL, reported 2024
At a glance
- Challenge. Accounts and private messages were at risk: provider tokens were not checked for audience or freshness, and linking needed only an address.
- Approach. We followed the linked login end to end, reused a provider token across accounts, tested linking by address, and read a thread from an account outside it.
- Result. Tokens are validated for audience and freshness, linking proves control of the address, threads enforce membership, and both surfaces were retested.
- Impact. An attacker could have entered another member's account by reusing a provider token or linking their own login to it, and read private threads they were not part of.
- Classification. CWE-1390 Weak Authentication, OWASP Top 10 (2021): A07 Identification and Authentication Failures. Component: Third-party login, account linking and message threads.
The challenge
Signing in with another provider works by trust: the platform believes the provider's statement about who you are. That trust holds only if the platform checks that the statement was meant for it, is still fresh, and matches the account being entered. When one of those checks is loose, the statement can be reused or redirected, and the trust becomes a way in rather than a convenience.
Account linking adds a second edge. If a login can be attached to an existing account by an address alone, without proving control of that address, then the attacker chooses whose account to link to. The provider did its job; the platform accepted the answer to a question it did not ask carefully enough.
Private messages sit behind the same kind of identifier check as any other record. If a message thread is fetched by a reference the server does not tie to the caller, private turns out to mean unlisted.
Our approach
We followed the linked login end to end and asked whether each token was audience-bound, fresh and matched to the account, and whether linking proved control of the address. We then tested whether a message thread could be read by an account that was not part of it.
Around those findings we checked the surface that shared the assumption:
- Whether the provider token was validated for audience and freshness
- Whether account linking proved control of the address
- Whether message threads enforced membership on the resolved thread
- Whether the same identifier gap reached other private records
Delivered with the tokens and requests used, so each finding could be reproduced against test accounts without taking our word for it.
From finding to fix
- Followed the linked login end to end
- Reused a provider token across accounts
- Linked a login and read private threads
- Bound and verified the login, retested
The outcome
Provider tokens are now validated for audience and freshness and matched to the account, and linking a login requires proving control of the address, so the trust can no longer be reused or redirected. Message threads enforce membership on the resolved thread.
We retested the login and messaging surfaces after the fix. Reported as CRITICAL in 2024. Retest included in the engagement.
Check your own system
- Reject any provider ID token whose audience is not your own client ID, even when the signature and issuer are valid.
- Enforce token expiry and a nonce bound to the sign-in request so a captured token cannot be presented again later.
- Require proof of control of the email address, or a sign-in to the existing account, before a new login is linked to it.
- Request a message thread from an account that is not a member and confirm the server checks membership on the thread it resolves.
Read more case studies, see Web Application Penetration Testing, or write to hello@yaamlabs.com.