Hunt Forgot Password
Hunt Forgot Password / Account Recovery Authentication Flaws, 5 distinct patterns: (1)...
Install
npx skills add elementalsouls/Claude-BugHunter --skill hunt-forgot-password -g -a claude-code -y- Repository
- elementalsouls/Claude-BugHunter5.4k
- Category
- Testing
- Updated
- 3d ago
- License
- MIT
- Context cost
- Lightabout 1,183 tokens
- Runs scripts
- No, instructions only
What it does
Hunt Forgot Password / Account Recovery Authentication Flaws, 5 distinct patterns: (1) username enumeration via different responses for valid vs invalid email, (2) reset token exposed directly in the API response body, (3) reset token not invalidated after use (replay), (4) password reset link works from a different IP/browser (no binding), (5) no rate limit on the reset request endpoint. These are the standalone recovery-flow broken-auth primitives, distinct from reset-email host-header poisoning (hunt-host-header) and the full ATO chain (hunt-ato owns password-reset as an ATO path; prove the primitive here, chain it there). Detection: trace the full forgot-password flow from request to token to use; check response diffs between valid/invalid emails; test token replay after consumption. Medium to High (enumeration=Medium, token-reuse=High, account-takeover=Critical when chained to known-email).
Autonomous Testing Priority
Start with username enumeration, it's the fastest win and gates the rest.
Pattern 1, Username enumeration (response difference for valid vs invalid email):
- POST to the forgot-password endpoint with a clearly invalid email (e.g.
nonexistent@fakedomain12345.com), record the response body, status code, and length - POST with an email you know exists (or try common patterns like
admin@target.com,test@target.com,user@target.com) - Compare responses: different message ("Email sent" vs "Email not found"), different HTTP status, or meaningfully different body length = username enumeration confirmed
- Proof: enumeration is confirmed when the two responses differ measurably (baseline vs probe) in message text, status code, or body length
Pattern 2, Reset token exposed in the API response: Some APIs return the reset token directly in the response body (instead of only emailing it). POST to the forgot-password endpoint and look for a token, link, or code in the JSON/HTML response. If a token appears that lets you reset the password, that's an immediate account-takeover vector.
Pattern 3, Reset token replay (reuse after use):
- Complete a full password reset cycle: request token → use it to reset password
- Immediately try submitting the same token again to the reset-password endpoint
- If the second submission returns 200 or "success" → token not invalidated after use
Pattern 4, No rate limit on reset requests: Submit the forgot-password endpoint 10-20 times rapidly with the same email. If all succeed without a 429, lockout, or CAPTCHA → no rate limit (enumeration + token flooding is possible).
Content-type: Forgot-password endpoints are often JSON-based REST APIs. Use application/x-www-form-urlencoded only if the endpoint is a traditional HTML form (check the login page's HTML to determine form encoding).
