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.
The client had passed an automated scan and wanted to know what that scan could not see. Scope covered registration, invitation, login, password reset, email change, role change and account deactivation, across three roles.
Reset tokens stayed valid longer than the interface implied and were not invalidated when a newer one was issued. Existing sessions survived a password change, so a session obtained earlier kept working after the owner had reset their password specifically to end it. A role downgrade did not take effect until the affected user signed out and back in, leaving the higher permission live in the meantime.
An attacker with any earlier foothold, a shared machine, a stolen session or an old reset link, retains access through exactly the actions a user takes to remove them. From the owner's side the account looks secured. It is not.
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.
Login and reset both work correctly in isolation in almost every application. The defects sit in what happens to state that already existed when the transition occurred.
Most users reset a password because they think somebody else has access. If other sessions survive it, the action did not do the one thing it was taken for.
If you write a role into a token, decide explicitly how quickly a revocation must take effect, and build for that. Silence here means the answer is whenever they happen to sign out.
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.
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.
