Understanding CORS Misconfiguration

In this article I will explain what cross-origin sharing is, give some examples and real case scenario and finally how to prevent from this misconfiguration.

CORS Explained

Cross origin sharing is a browser mechanism which control
to access resources from another domain. This can be used to share resources between different domains, or to allow a web page to access resources from a domain that is not the same as the domain from which the web page was served.
CORS was originally create to add more flexibility yo same-origin policy mechanism (SOP). SOP prevent website to attacking each other by implement a strict policy which describe how website can reach each other.
The cross-origin resource sharing uses a suite of HTTP headers that define trusts web domains origins and associated properties.

Allow an Origin

In order to allow a specific origin the header 'Allow-Control-Origin" has to be included in the response from a website which receive a CORS request.
The browser compare the value of the header with the requesting website's origin and allow access if they correspond.
Concert example :
A website wants to use a resource from a remote host.

GET /data HTTP/1.1Host: remote-website.comOrigin : https://test-website.com

The server of the requesting website (remote-website.com) return the following response:

HTTP/1.1 200 OK...Access-Control-Allow-Origin: https://test-website.com

The browser will compare the response and in this case the browser will permit because the origins match.

In the case where there is no restriction the server will return wildcard into the server header.

Allow Credentials

Cross-origin resource requests are sent without credentials such as cookies and the Authorization header by default.
When credentials are supplied to the cross-domain server, the CORS Access-Control-Allow-Credentials header is set to true, allowing reading of the response. Then the browser will permit the requesting website to get the response.

Access-Control-Allow-Credentials: true

Security Issues

Unfortunately give flexibility often generate security issues.
If a website's CORS is poorly configured it is can potentially lead to cross-domain attacks.
Take a bank virtual as example, suppose that an attacker stole user's cookies the attacker will send the following request:

GET /account-details HTTP/1.1Host: virutal-bank.comOrigin: https://malicious-website.comCookie: sessionid=..

Then the bank's server will respond :

HTTP/1.1 200 OKAccess-Control-Allow-Origin: https://malicious-website.comAccess-Control-Allow-Credentials: true

The response's server allows the malicious attacker to send cross request, and that the request can include cookies .
In this case because the App reflects arbirtrary subdomain from the origin header , theoretically every domains can access ressources from this vulnerable bank's website.
In result with a bad CORS configuration an attacker could read sensitive bank's information.

Does CORS protect against CSRF?

CORS does not specifically protect against CSRF, but it does add an extra layer of security. If an attacker does manage to exploit a CSRF vulnerability, they will only be able to access resources that are allowed by the CORS policy.

How to protect against CORS Misconfiguration?

Misconfigurations are the primary cause of CORS vulnerabilities.
Proper setting is critical to preventing these threats.
The sections that follow outline several viable CORS defenses.

If a web resource includes sensitive information, make sure the origin is appropriately stated in the Access-Control-Allow-Origin header.

Allow only trustworthy websites access to the resource.
It is especially dangerous to dynamically reflect origins from cross-origin requests without validation.

Use the Access-Control-Allow-Origin: null header as little as possible.
Cross-origin resource calls from internal documents and sandboxed requests can have a null origin specified.
For both private and public servers, CORS headers should be appropriately established in terms of trustworthy origins.

Internal networks should be free of wildcards.
When internal browsers may access untrusted external sites, relying on network setup alone to safeguard internal resources is insufficient.

Check your API security at www.blstsecurity.com.