Single sign-on was configured so that the identity returned by the provider was trusted more than the account it was being attached to. The result was an account linking path that let one identity end up in control of a different user's account. This is the class of issue that reads as a configuration detail and behaves as a full account takeover.
The platform had added social login after the fact, on top of an existing email and password system. Both paths could reach the same account. Testing focused on what happens at the join between them, because that join is where two sets of assumptions meet and neither side owns the result.
The application treated the address returned by the provider as proof of ownership and used it to attach the identity to an existing account. It did not require the user to already be authenticated in that account, and it did not check whether the provider had verified the address. An attacker able to present a chosen address through the flow could reach an account that was never theirs.
Full access to another user's account and everything inside it, without needing that user's password and without triggering a password reset email that might have warned them. Multi-factor authentication on the password path did not help, because the attack does not use the password path.
None of these needs a purchase order. They are the checks that most often turn up something on a system nobody has looked at from the outside.
Social login is usually fine on its own and the password system is usually fine on its own. The bug lives where they meet. If you have added sign-in methods over time, the linking logic is the first thing to have looked at.
Any flow that grants access because an address matches is trusting a value that other systems hand out freely. Ownership has to be proven inside your application, at the moment access is granted.
If multi-factor authentication is enforced at password login but not on the single sign-on path or the reset path, then it is optional in practice.
Reviewing authentication as a lifecycle rather than a login page surfaced several issues that individually looked minor and together produced a reliable way to hold access to an account after the owner had tried to lock it down. Most of these do not appear in scanner output at all, because every response involved is a legitimate one.
Two classic injection classes, both reachable only after login, which is why neither had ever been reported by an unauthenticated scan. The database defect exposed data across the whole application. The scripting defect ran in the browser of whoever reviewed the affected record, which in this product was always an administrator.
Tell us what you are running and which of these worries you. We will tell you plainly whether it is worth testing, what it would cost, and when the answer is that you should fix something yourself first.
Ask about services, pricing, how an engagement runs, or what we do not do. I can also book you a call.
