CORS and Its Misconfigurations

Before Understanding CORS, we need to know about SOP(Same Origin Policy). SOP is built as a security mechanism to safeguard web applications from requesting resources from another website.

In a Simple way, your-website.com cannot access resources from another-website.com. So, to access resources, those 2 websites must have same protocol(HTTP/HTTPS), same domain name , same port number(80/443).

Note:- Even a subdomain such as api.your-website.com do not have access to fetch domain from its root domain(your-webiste.com) because those 2 websites have different domain according to rules of SOP.

If your website(your-website.com) needs access to api.your-website.com, then we need to enable/Configure CORS(Cross-Origin Resource Sharing) for that website to access a resource.

To configure CORS, the website will set headers such as Access-Control-Allow-Origin and Access-Control-Allow-Credentials. Although there are more headers to configure cors, these are the widely used methods today.

Access-Control-Allow-Origin:- Values of this Cors Header can be 2 things,

1) another-website.com:- Here there can be a specific website that tells that only that website is allowed to access the resource

2) *:- There can be * which says that any website irrespective of the domain, protocol, the port can access the resource.

Access-Control-Allow-Credentials:- (True/False)Third-party websites can carry out privileged actions. Think of this as an attacker conducting changes that only you, the authenticated user, should be able to.

So, While Configuring Cors, Misconfiguration happens when developers set these headers in the wrong way. This types of misconfigurations can vary depending on the deployment. Below are the most common configurations and their corresponding risks.

1. Exploiting misconfigured wildcard(*) in CORS Headers

Most common misconguration of cors is using wildcard in `Access-Control-Allow-Origin` which says that any domain can acccess the resource irresepective of the rules of SOP.

For Example:-

GET /api/userinfo.php
Host:- www.victim.com
Origin:- www.victim.com

When you send the above request , you typically receive a response as below

_HTTP/1.0 200 OK 
Access-Control-Allow-Origin: * 
Access-Control-Allow-Credentials: true 

So, here as an attacker, we can set the origin as `https://attacker.com` and send the request. Then we will have same response as above because any domain is allowed to access the resource as per wildcard configuration.

2) Trusting pre-domain wildcard as origin

Another common way CORS misconfigurations are exploited is by allowing information sharing with domain names that are partly validated. For Example, consider the below REQUEST.

GET /api/userinfo.php
Host:provider.com
Origin:requester.com

And the response to the above request would be

HTTP/1.0 200 OK
Access-Control-Allow-Origin: requester.com
Access-Control-Allow-Credentials: true

Consider if a developer had configured CORS to validate the “Origin header” URL, with the white listed domain as just “requester.com”. Now, when the attacker crafts the REQUEST as below.

GET /api/userinfo.php
Host: example.com
Connection: close
Origin: attackerrequester.com

The unassuming server would respond with

HTTP/1.0 200 OK
Access-Control-Allow-Origin: attackerrequester.com
Access-Control-Allow-Credentials: true

This has occured because the validation has occured poorly in the backend where it is just checking for the presence of `requester.com`.

That’s it, thank you so much for reading :)