Email verification bypass

Why This Matters

Email verification is a trust anchor in account registration flows, preventing adversaries from registering accounts with other people's email addresses and establishing verified identity for downstream operations. Bypasses in this flow have enabled account pre-hijacking attacks — a technique documented by security researcher Avinash Sudhodanan in a 2022 research paper that affected major services including Dropbox, Instagram, and LinkedIn at the time of discovery. When verification tokens are predictable, the attacker can pre-register a victim's email and gain control of the account before the legitimate user does, or take over an existing unverified account.

Core Concept

Email verification is intended to prove that the registering party controls the email address they claimed. The server generates a verification token, associates it with the pending account, includes it in an email to the claimed address, and grants full account access only after the token is presented back. The security invariant is that the verification token must be unpredictable to anyone who does not control the mailbox.

Token predictability is the primary vulnerability class. The weakest implementations use a sequential integer (/verify?token=1042), the user's numeric ID, or a timestamp in milliseconds. Slightly stronger but still broken implementations use MD5(email + timestamp) or MD5(email). An attacker who registers their own account and observes the structure of their own verification token can deduce the algorithm and calculate the token for any other registered account within a predictable time window.

Step skipping is the logic-flaw variant: an application that stores is_verified = 0 in the user record and then checks this flag on login can be bypassed if the flag is passed in the registration completion request and the server accepts it from the client. Submitting is_verified=1 in the registration form or in the JSON payload activates the account without ever receiving the verification email.

Response manipulation applies when the verification endpoint returns {"verified": false} for an incorrect token and the client-side code is responsible for acting on this response — changing false to true in Burp Proxy causes the browser to redirect to the authenticated dashboard as if verification succeeded.

Token reuse across accounts occurs when the verification token is not bound to a specific user record but is instead a global HMAC of just the email address or a shared secret. An attacker who receives a valid token for their own email and applies it against a different account's verification URL may find the server accepts it.

Technical Deep-Dive

Analysing token predictability:

# Register two accounts in quick succession, observe tokens:
# Account 1 (registered at T=1712345000): token=a1b2c3d4
# Account 2 (registered at T=1712345001): token=a1b2c3d5
# Sequential increment → trivially enumerable

# MD5-based token analysis
python3 -c "
import hashlib, time
email = '[email protected]'
ts = int(time.time())
for delta in range(-60, 61):  # ±60 second window
    candidate = hashlib.md5(f'{email}{ts+delta}'.encode()).hexdigest()
    print(f'T+{delta:+d}: {candidate}')
"
# Compare against observed token to find the matching timestamp

Testing is_verified parameter injection:

POST /register/complete HTTP/1.1
Host: target.example.com
Content-Type: application/json

{
  "email": "[email protected]",
  "username": "attacker",
  "password": "P@ssw0rd",
  "is_verified": true,
  "verified": 1,
  "email_confirmed": true
}

Response manipulation in Burp Proxy:

-- Server sends to browser:
HTTP/1.1 400 Bad Request
{"status": "error", "verified": false, "message": "Invalid token"}

-- Attacker modifies before browser receives:
HTTP/1.1 200 OK
{"status": "success", "verified": true, "message": "Email verified"}
-- If browser now redirects to /dashboard with a new session cookie, logic runs client-side

Token enumeration with Burp Intruder:

GET /verify?token=§10001§ HTTP/1.1
Host: target.example.com

-- Payload type: Numbers, from 10000 to 20000, step 1
-- Grep match: "verified successfully" or redirect to /login

Security Assessment Methodology

1. Register a test account and capture the verification token — Note the token value, length, character set, and the time elapsed between registration and email receipt. Register a second account immediately after and compare the two tokens for sequential patterns or shared structure.
2. Attempt token algorithm reversal — If the token looks like a hash, test MD5(email), MD5(email+timestamp), SHA1(user_id), and similar combinations using the known values from your test account. A match proves the algorithm.
3. Test step-skipping via parameter injection — Submit is_verified=true, verified=1, confirmed=true, and email_confirmed=1 in the registration completion request body and query string. Also test via JSON type coercion ("is_verified": true vs "is_verified": "true").
4. Test response manipulation — Use Burp Proxy to intercept the response from the verification endpoint when an invalid token is submitted. Modify the response to indicate success and observe whether the application grants access.
5. Test token reuse across accounts — Generate a valid token for your own account. Attempt to use it in the verification URL for a different account (change the user ID or email parameter in the URL).
6. Test token expiry — Use a verification token more than 24 hours after receipt (if possible) or reuse it after successful verification. Tokens must expire and must be invalidated after first use.

Defensive Countermeasure — Generate verification tokens using a CSPRNG producing at least 128 bits of entropy, store only the SHA-256 hash of the token server-side, bind the token to the specific user record by including the user ID in the MAC computation, and invalidate the token immediately upon first successful use with a maximum validity window of 24 hours.

Common Assessment Errors

• Testing only the happy path — Sending the correct token to confirm verification is not a security test. The test is whether incorrect, predictable, or replayed tokens are accepted.
• Not registering two accounts to compare tokens — Single-account analysis cannot detect sequential patterns. Always register at least two accounts within a short time window and compare.
• Stopping at "token appears random" — A token that looks random may still be derived from a weak hash. Attempt algorithmic reversal using all known input values before concluding the token is securely generated.
• Ignoring the URL structure — Verification URLs often include both a token and a user ID: /verify?user=42&token=abc. If the token is not bound to the user, submitting the correct token with a different user ID is the bypass.
• Not testing the pre-hijacking scenario — Register with the victim's email address before the victim does. If the application allows this and the verification token is guessable, the attacker can pre-compromise the account.
• Missing the account enumeration leak — A verification endpoint that responds differently to "token invalid" vs "account not found" leaks registered email addresses. Report this as a secondary finding.

NICE Framework Alignment

Further Reading

• Pre-hijacking Attacks on Web User Accounts — Avinash Sudhodanan & Andrew Paverd (Microsoft Security Response Centre Research, 2022)
• OWASP Testing Guide v4.2, OTG-AUTHN-002: Testing for Default Credentials — OWASP Foundation
• OWASP Cheat Sheet Series: Authentication — OWASP Foundation