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 "access-control-allow-origin"

Phase 2 — Reflect-any-origin + null origin

# Does the server reflect an arbitrary Origin back?
curl -s -D - -o /dev/null https://$TARGET/api/me \
  -H "Origin: https://evil.com" \
  -H "Cookie: $SESSION_COOKIE" | grep -i "access-control"

# Vulnerable (the High case):
#   Access-Control-Allow-Origin: https://evil.com   <- reflects attacker origin
#   Access-Control-Allow-Credentials: true          <- + credentials => readable
#
# NOT exploitable for credentialed theft:
#   Access-Control-Allow-Origin: *                   <- browser blocks creds read
#   (no ACAC, or ACAC absent)                        <- not credentialed

# Null-origin trust
curl -s -D - -o /dev/null https://$TARGET/api/me \
  -H "Origin: null" \
  -H "Cookie: $SESSION_COOKIE" | grep -i "access-control"
# Looking for:  Access-Control-Allow-Origin: null  +  ACAC: true

Phase 3 — Subdomain / trusted-origin regex bypass

The right payload depends on which regex flaw the server has. Identify the class first, then send the matching payload. Getting this wrong wastes the test and produces false negatives.

# Send each class-specific payload and watch what the server reflects.
for ORIGIN in \
  "https://evil.target.com" \
  "https://eviltarget.com" \
  "https://x.target.com.evil.com" \
  "https://target.com.evil.com" \
  "https://target.com%60.evil.com" \
  "http://target.com"; do
  RESULT=$(curl -s -D - -o /dev/null "https://$TARGET/api/me" \
    -H "Origin: $ORIGIN" \
    -H "Cookie: $SESSION_COOKIE" | grep -i "access-control")
  echo "[$ORIGIN] -> ${RESULT:-no CORS}"
done

A bypass is real only if the server reflects your registerable origin into ACAO with ACAC: true. evil.target.com reflecting back is NOT a bug unless you can actually control a *.target.com host (then see Phase 6 / hunt-subdomain).

Phase 3b — Trusted insecure (HTTP) origin

If ACAO reflects/allows any http:// origin (even a correctly-anchored in-scope one) with ACAC:true, a network attacker on that cleartext host injects a page that reads the authed cross-origin body — no regex flaw needed, the plaintext scheme IS the flaw.

curl -s -D- -o/dev/null "https://$TARGET/api/me" -H "Origin: http://sub.$TARGET" -H "Cookie: $SESSION" | grep -i access-control

Real only if a MITM can occupy that http origin (no HSTS-preload). Pair with hunt-tls-network. (PortSwigger: CORS with trusted insecure protocols.)

Phase 4 — Pre-flight (OPTIONS) gating bypass

Non-simple requests (custom headers, PUT/DELETE/PATCH, non-simple Content-Type) trigger a CORS pre-flight OPTIONS. The browser only sends the real request if the pre-flight response authorizes the method/header. Two things to test:

1. Does the pre-flight authorize arbitrary methods/headers for your origin? If Access-Control-Allow-Methods / Access-Control-Allow-Headers reflect whatever you ask for, a malicious origin can drive state-changing requests (chain to CSRF-style writes that JSON/SameSite would otherwise block).

curl -s -D - -o /dev/null -X OPTIONS "https://$TARGET/api/account/email" \
  -H "Origin: https://evil.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: x-custom-auth, content-type" \
  | grep -i "access-control"
# Vulnerable: ACAO reflects evil.com + ACAC:true +
#   Access-Control-Allow-Methods: PUT  +  Access-Control-Allow-Headers: x-custom-auth
# => attacker origin can issue authed PUT/DELETE with custom headers.

2. Is the pre-flight even enforced server-side? Some servers reflect the origin on OPTIONS but the actual GET/POST also reflects — the read path is the bug; the pre-flight just confirms write-path reach. Test the GET/POST directly too — never assume the pre-flight result equals the real-request result. Confirm in a browser, because curl ignores CORS entirely.