hunt-cors

> **⚠️ 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-CORS — Cross-Origin Resource Sharing Misconfiguration

What actually pays (and what does not)

CORS pays High **only** when an attacker-controlled origin can perform a

**credentialed** cross-origin read of sensitive authenticated data, and you

have a browser PoC proving the response body is readable from `evil.com`.

Two hard browser rules that kill most "findings" — check these FIRST:

- **`Access-Control-Allow-Origin: *` CANNOT be combined with credentials.**

If the server returns `ACAO: *`, the browser refuses to send/expose the

response for a `credentials: include` request. A wildcard-only endpoint is

**not** credential-exploitable. It is only interesting if the data it serves

is sensitive *without* a session (rare) — usually this is Informational/Low.

- **`Access-Control-Allow-Credentials: true` is meaningless on its own.** It

matters only if `ACAO` reflects/allows your specific attacker origin AND a

cross-origin credentialed `fetch` actually returns a readable body. ACAC on a

response that does not reflect your origin proves nothing.

If you cannot demonstrate a readable cross-origin authed body in a real

browser, you do not have a High. Do not submit header-diffing alone.

---

Crown Jewel Targets

- **Reflect-any-origin + credentials** — server echoes the `Origin` header AND

sets `ACAC: true` → any site reads authed API responses. The classic High.

- **Null-origin trust** — `ACAO: null` + `ACAC: true`. A `sandbox` iframe (or a

`data:`/redirect chain) emits `Origin: null`, so any page can read authed data.

- **Subdomain-regex bypass** — trusted-origin regex with a parsing flaw. The

correct payload depends on *which* flaw (see Phase 3 — this is where most

skills get it wrong).

- **Subdomain takeover → trusted origin** — a dangling subdomain that the CORS

policy trusts; take it over, host the PoC there (see hunt-subdomain).

- **postMessage missing/loose origin check** — handler that processes

`event.data` without strictly validating `event.origin`.

---

Attack Surface Signals

Any endpoint returning an Access-Control-Allow-Origin header
API endpoints:   /api/*, /v1/*, /graphql
Profile/account: /api/me, /api/profile, /api/user, /api/session
Secrets/tokens:  /api/tokens, /api/keys, /api/csrf, /api/account/settings
Financial:       /api/balance, /api/transactions
Admin/internal:  /api/admin/*, /api/internal/*

Prioritize endpoints that (a) require a session cookie and (b) return PII,

tokens, CSRF tokens, or other secrets in the body.

---

Step-by-Step Hunting Methodology

Phase 1 — Discover CORS endpoints

# Probe API endpoints. Use GET (not -I): some servers only emit CORS on GET,
# and -I sends HEAD which may be handled differently.
while read url; do
  result=$(curl -s -D - -o /dev/null "$url" \
    -H "Origin: https://evil.com" \
    -H "Cookie: $SESSION_COOKIE" | grep -i "access-control")
  [ -n "$result" ] && echo "=== $url ===" && echo "$result"
done < recon/$TARGET/api-endpoints.txt

# httpx bulk check
cat recon/$TARGET/live-hosts.txt | awk '{print $1}' | \
  httpx -H "Origin: https://evil.com" -match-string "ac