Demystifying CORS

CORS can only be completed by mentioning SOP or same-origin policy. So we should start with SOP before diving into CORS.

What is SOP ???

The same-origin policy is a web browser security mechanism that aims to prevent websites from attacking each other. The same-origin policy restricts scripts on one origin from accessing data from another origin. — Portswigger.net

In other words, it’s a policy that prevents the javascript (JS) of one website from accessing the resources of another website.

More realistically, we could frame this as “Without SOP, if you visit a malicious website, it would be able to read or modify the contents of your bank account, read your emails and private messages from your social media accounts, etc”

So let’s understand the origin in the first place!

Two URLs are from the same origin if the protocol, port, and domain (not subdomains) are the same for both URLs. Difficult let's see the diagram for a clear understanding

The following table gives examples of origin comparisons with the URL http://store.company.com/dir/page.html:

Hope the table has made the concept of origin clear to you. But at the same time this is the age of microservices where web developer uses cdn and similar stuff to optimize the performance of their website, Does SOP equally block them?? The table below will address the problem statement

So from the table above More or less, it is an XHR request(javascript based) made by one site to another under the lens of SOP.

When we try to access one sensitive page of a website from another website using javascript calls browser will stop such request and throw a CORS error (something like given below)

How does CORS help in circumventing SOP?

For CORS following headers play a big role

The following three response headers are the most important for security:

Access-Control-Allow-Origin specifies which domains can access a domain’s resources. For instance, if giveme.com wants to access resource.com’s resources, then developers can use this header to securely grant giveme.com access to resource.com’s resources.Access-Control-Allow-Credentials specifies whether or not the browser will send session cookies with the request. Session Cookies will only be sent if the allow-credentials header is set to true.Access-Control-Allow-Methods specifies which HTTP request methods (GET, PUT, DELETE, etc.) can access resources. This header lets developers further enhance security by specifying what methods are valid when giveme.com requests access to resource.com’s resources.

What are the possible attack scenarios for CORS:

Exploiting misconfigured wildcard (*) in CORS Headers:

One of the most common CORS misconfigurations is incorrectly using wildcards such as (*). But in this scenario SOP policy of the browser will not allow you to set the ACAC(Access Control Allow credential) flag as True. So virtually it would appear that you can attack, but not an exploitable scenario

But one interesting case study you may refer

2. Trusting arbitrary Origin:- Here the origin header is loosely stated by the application, therefore attacker could exploit the scenario if ACAC is set to True.

Demo of this attack:-

3. Poor Whitelisting of origin Header: Suppose the application developer has allowed a specific domain for accessing the response through XHR, if this Whitelisting is not properly managed then also an attacker can exploit this scenario.

(If not understood then stay tuned will come up with its demo)

4. XSS in subdomain: Again it is in continuation of point 3, where a wildcard domain is whitelisted for the Origin header(e.g *.domain), in this case, an attacker may look for an XSS in the subdomain and chain the same for exploiting. (Demo is under preparation so stay tuned)

Thanks for your time!!! Post your comment with your views :)