Registration & Account Takeover Vulnerability Testing

A comprehensive methodology for testing registration flows and account takeover vectors in web applications.

Quick Start

1. Identify registration endpoints - Find signup, password reset, email change, and verification endpoints
2. Test duplicate registration - Try creating accounts with existing credentials using email tricks
3. Check verification weaknesses - Test OTP, magic links, and email verification flows
4. Attempt account takeover - Test password reset, IDOR, and pre-hijacking techniques
5. Validate session handling - Ensure old sessions are invalidated after password/email changes

Registration Takeover Testing

Duplicate Registration Attacks

Test if you can create duplicate accounts or bypass uniqueness checks:

Email manipulation techniques:

• Uppercase variations:

  Victim@Example.com

• Subaddressing:

  victim+1@gmail.com

  ,

  victim+test@gmail.com

• Dot insertion (Gmail):

  v.i.c.t.i.m@gmail.com

• Special characters:

  %00

  ,

  %09

  ,

  %20

  in email name
• Trailing spaces:

  test@test.com a

• Double @ tricks:

  victim@gmail.com@attacker.com

• Unicode confusables and homoglyphs
• Soft hyphen:

  \u00AD

  within local-part

Test cases to run:

1. Register with victim's email using variations above
2. Check if duplicate account is created
3. Verify if you receive verification emails
4. Test if you can block victim signups (DoS)
5. Check for workspace/invite bypass

Username Enumeration

Determine if usernames are enumerable:

Indicators to check:

• Different error messages for existing vs. new users
• HTTP status code differences (200 vs 400/404)
• Timing differences (existing user triggers DB lookup)
• Registration form autofill revealing profile data
• Team/invite flows revealing account existence

Testing approach:

1. Submit registration with known email - note response
2. Submit with unknown email - compare response
3. Measure response times for both
4. Check for timing-based enumeration

Password Policy Testing

Check password requirements and weaknesses:

Tests to perform:

• Try weak passwords (123456, password, etc.)
• Test minimum/maximum length requirements
• Check character class requirements
• Attempt bruteforce if weak policy detected
• Test for password complexity bypass

Verification Weakness Testing

OTP/Magic Link Vulnerabilities

Common flaws to test:

1. Guessable OTP

   • Short codes (4-6 digits)
   • No rate limiting or weak rate limiting
   • No IP/device tracking
   • Test parallel guessing with header/IP rotation

2. OTP Reuse

   • Same code works for login and signup
   • Code works after email change
   • Code not bound to specific user/action

3. Multi-value Smuggling

   code=000000&code=123456
   {"code":["000000","123456"]}
   otp=000000&one_time_code=123456
   code=000000,123456
   code=000000|123456
   

4. Response Oracle

   • Distinguish wrong vs. expired vs. wrong-user codes
   • Check status codes, messages, body lengths

5. Token Invalidation

   • Tokens not invalidated after success
   • Tokens work after password/email change
   • Tokens not tied to user agent/IP

Bruteforce testing with ffuf:

ffuf -w <wordlist> -u https://target.tld/api/verify -X POST \
  -H 'Content-Type: application/json' \
  -d '{"email":"victim@example.com","code":"FUZZ"}' \
  -fr 'Invalid|Too many attempts' -mc all

Race condition testing:

• Submit same valid OTP simultaneously in two sessions
• One session may become verified attacker account
• Victim flow may also succeed

Email Verification Testing

Tests to perform:

• Host header poisoning on verification links
• Cross-origin completion from attacker pages
• Token leakage via referrer header
• Unverified email acceptance

Password Reset Takeover

Token Leak via Referrer

1. Request password reset to your email
2. Click the reset link
3. Don't change password
4. Click any third-party website
5. Intercept request in Burp Suite
6. Check if Referer header leaks reset token

Password Reset Poisoning

Host header manipulation:

http POST https://example.com/reset.php \
  HTTP/1.1 \
  Accept: '*/*' \
  Content-Type: 'application/json' \
  Host: 'attacker.com' \
  X-Forwarded-Host: 'attacker.com'

Look for reset URLs based on host header like:

https://attacker.com/reset-password.php?token=TOKEN

Email Parameter Manipulation

Parameter pollution:

email=victim@mail.com&email=hacker@mail.com
{"email":["victim@mail.com","hacker@mail.com"]}
email=victim@mail.com%0A%0Dcc:hacker@mail.com
email=victim@mail.com%0A%0Dbcc:hacker@mail.com
email=victim@mail.com,hacker@mail.com
email=victim@mail.com%20hacker@mail.com
email=victim@mail.com|hacker@mail.com

IDOR on Password Reset

1. Login with your account
2. Go to change password feature
3. Intercept request in Burp Suite
4. Edit user ID/email parameter to victim's
5. Attempt password change

Weak Reset Token Testing

Check for predictable tokens:

• Timestamp-based generation
• UserID or email in token
• Personal info (name, DOB) in token
• Weak cryptography
• Number-only tokens
• Small character set
• Token reuse across requests
• No expiration or long expiration

Username Collision Attack

1. Register with username identical to victim's but with whitespace:

   "admin "

2. Request password reset with malicious username
3. Use token sent to your email
4. Reset victim's password
5. Login to victim account

Pre-Hijacking Techniques

Test attacks that occur before victim signs up:

Classic-Federated Merge

1. Attacker registers classic account with victim email + password
2. Victim later signs up with SSO (same email)
3. Insecure merge may leave both parties logged in
4. Attacker may regain access

Unexpired Session Identifier

1. Attacker creates account, holds long-lived session
2. Victim recovers/sets password, uses account
3. Test if old sessions stay valid after reset/MFA

Trojan Identifier

1. Attacker adds secondary identifier to pre-created account
2. Victim resets password
3. Attacker uses trojan identifier to reset/login later

Unexpired Email Change

1. Attacker initiates email change to attacker mail
2. Withholds confirmation
3. Victim recovers account, starts using it
4. Attacker completes pending email change to steal account

Non-Verifying IdP

1. Attacker uses IdP that doesn't verify email ownership
2. Asserts victim email via SSO
3. Service merges without checking email_verified

Registration-as-Reset (Upsert)

Some signup handlers perform upsert on existing email:

Discovery:

• Harvest endpoint names from bundled JS/mobile traffic
• Fuzz base paths:

  /parents/application/v4/admin/FUZZ

• GET returning "Only POST request is allowed" indicates correct verb

Minimal body example:

{"email":"victim@example.com","password":"New@12345"}

Example request:

POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
Host: www.target.tld
Content-Type: application/json

{"email":"victim@example.com","password":"New@12345"}

Impact: Full Account Takeover without reset token, OTP, or email verification.

Additional Testing

Disposable Email Bypass

• Test with mailinator, yopmail, 1secmail
• Bypass blocklist with subaddressing:

  victim+mailinator@gmail.com

DoS Testing

• Long passwords (>200 characters)
• Check rate limits on account creation
• Test for resource exhaustion

Callback Analysis

• Use

  username@burp_collab.net

• Analyze callback behavior
• Check for information disclosure

Phone Number Testing

• Test phone parsing/injection edge cases
• Check for SMS bombing
• Verify phone number validation

Captcha Bypass

• Test captcha solving
• Check for bypass techniques
• Verify rate limiting effectiveness

Contact Discovery Oracles

Phone-number-centric messengers expose presence oracles:

1. Instrument official client to capture address-book upload
2. Batch numbers per request - thousands of identifiers
3. Horizontally scale with SIM banks, cloud devices, proxies

Dialing-plan modeling:

• Model each country's dialing plan
• Skip invalid candidates
• Prioritize high-hit ranges

Turning enumerations into attacks:

• Feed leaked phone numbers into oracle
• Slice censuses by country/OS/app type
• Find regions with weak SMS filtering

Session Validation Checklist

After any password reset or email change, verify:

• All other sessions and tokens are invalidated
• Pending email/phone change capabilities are cancelled
• Previously linked IdPs/emails/phones are re-verified
• MFA settings are properly handled

Tools Reference

• Burp Suite - Request interception and modification
• ffuf - Directory and parameter fuzzing
• Turbo Intruder - Parallel/concurrent request flooding
• Smuggler - HTTP request smuggling detection
• Burp Collaborator - Out-of-band interaction testing

Reporting

When documenting findings:

1. Include exact request/response pairs
2. Show proof of concept with screenshots
3. Explain impact clearly (ATO, enumeration, DoS)
4. Provide remediation recommendations
5. Reference CVEs if applicable

Safety Notes

• Only test systems you have authorization to test
• Document all testing activities
• Avoid causing service disruption
• Handle discovered credentials responsibly
• Follow responsible disclosure practices