caon.io

Account Takeover

Rarely one bug. Usually a weak reset, a loose email check and a trusting session store, chained.

Password reset

The highest-yield surface on most programs.

# host header poisoning — the link is built from the request
POST /reset
Host: oob.tld
X-Forwarded-Host: oob.tld
  • Is the token in the Referer when the reset page loads a third-party script?
  • Does the token expire after use? After a new one is issued? On password change?
  • Is it a UUIDv1, a timestamp, an incrementing id, or md5(email)?
  • Does changing the password invalidate other sessions?
  • Two accounts, request both resets, swap the tokens
  • Send [email protected]&[email protected] — see Parameter Pollution
  • Array the parameter: {"email":["[email protected]","[email protected]"]}

Email normalisation

Two systems, two opinions about what the same address is.

[email protected]
[email protected].              trailing dot
[email protected]               case
[email protected]               Gmail dots
victim+[email protected]             plus alias
[email protected]@evil.tld
"[email protected]"@evil.tld
[email protected]%[email protected]
victim@targeṭ.com               unicode / punycode confusable
victim@[127.0.0.1]

Signup normalises one way, lookup the other → you own the victim’s record.

Unicode case-folding is the sharp one: ᴠictim or a dotless ı that upper-cases into I.

Registration

  • Register an account that already exists — does it overwrite or link?
  • Register [email protected] unverified, then have them sign up with SSO and get merged
  • Skip email verification: does any endpoint work before it?
  • Sign up with the victim’s phone number

OAuth and SSO

See OAuth for the full flow. The ATO-relevant parts:

  • Account linking by email without verifying the email at the IdP
  • redirect_uri allow-list bypass → code theft
  • Missing state → login CSRF, victim ends up in your account
  • Pre-account-takeover: register the victim’s email with a password before they first use SSO

Session

  • Does logout revoke server-side or only clear the cookie?
  • Is the session id rotated at login and at privilege change?
  • Are JWTs revocable? See JWT
  • Password change → are old sessions killed?
  • Is there a “devices” list, and does removing one actually work?

2FA

  • Race the OTP validation — see Race Conditions
  • Response manipulation: {"verified":false}true
  • Backup codes generated before 2FA was enabled
  • Is 2FA enforced on the reset flow, or only on login?
  • Does the pre-2FA session already carry full privileges?

A takeover on any *.target.com origin — including one you got by Subdomain Takeover — reaches every cookie set on the parent domain.

Writing it up

Chain reports get downgraded when the steps are listed separately. Give one numbered path from unauthenticated to session, name each primitive, and state which single fix breaks the chain.

Articles

↑↓ navigate↵ openesc close