Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP

headers to tell browsers to give a web application running at one origin, access to
selected resources from a different origin. A web application executes a cross-
origin HTTP request when it requests a resource that has a different origin
(domain, protocol, or port) from its own.
There are a number of HTTP headers related to CORS, but 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 requester.com want to access provider.com’s resources,
then developers can use this header to securely grant requester.com access to
provider.com’s resources.
Access-Control-Allow-Credentials specifies whether or not the browser will send
cookies with the request. 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 be used to access resources. This header lets developers further
enhance security by specifying what methods are valid when requester.com requests
access to provider.com’s resources.

1) Exploiting misconfigured wildcard (*) in CORS Headers:

One of the most common CORS misconfigurations is incorrectly using wildcards such
as (*) under which domains are allowed to request resources. This is usually set as
default, which means any domain can access resources on this site. For example,
consider the below request:

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

When you send the above request, you get a response with the Access-Control-Allow-
Origin header setting. See the below response code.

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

In this example case, the header is configured with a wildcard(*). It means any
domain can access the resources.

While testing one of our client’s web application, we noticed this exact
misconfiguration. We were able to exploit it to fetch user information like Name,
User-ID, Email-ID and were able to send this information to an external server. In
the below image, we modified the REQUEST Origin from victim domain to attacker
domain.

Tampered origin URL under request

Image: Tampered origin URL under REQUEST

Below is the response we received. The wildcard is shown in the origin header
response with Access-Control-Allow-Origin: *, which means victim domain allows
access to resources from all sites. Testing.aaa.com site in our attack case.

Response from the request

Image: Response from the REQUEST

Since the site shares information from any site, we went further and exploited it
using our own domain. We created our domain called https://testing.aaa.com, and
embed it with exploit code to steal the confidential information form the
vulnerable application. When victims open https://testing.aaa.com in the browser,
it retrieves the sensitive information and sends to the attacker’s server. See
below image for the kind of information you can gather with this attack.

Application sends sensitive information to attackers

Image: Application sends sensitive information to attackers

2) Trusting Pre-domain Wildcard as Origin:

Another common misconfiguration is 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

The reason this happens is a possible backend badly configured validation such as
this:

if ($_SERVER['HTTP_HOST'] == '*requester.com')
{
//Access data
else{ // unauthorized access}
}

We came across this in one of our client’s application. The host domain
“provider.com” trusted all origins that ended with host name “requester.com” such
as “attackerrequester.com”. So, we tampered the origin header to
attackerrequester.com and proceeded with the request.

Tampered origin URL under request.

Image: Tampered origin URL under REQUEST

In the below response, the same origin is reflected in the response Access-control-
Allow-Origin header, which means provider.com domain allows sharing resources to
domains which end with requester.com domain.

Response from the request

Image: Response from the REQUEST

This can be exploited the same way we did for the first misconfiguration. We can
create a new domain with the name consisting of the whitelisted domain name. Then,
embed that malicious site with exploits that will fetch sensitive information from
the victim’s site.

3) Using XSS to make requests to cross origin sites

One defense mechanism developers use against CORS exploitation is to whitelist

domains that frequently requests access for information. However, this isn’t
entirely secure, because if even one of the subdomains of the whitelisted domain is
vulnerable to other exploits such as XSS, it can enable CORS exploitation.

Let us consider an example, the following code shows the configuration that allows
subdomains of requester.com to access resources of provider.com.

if ($_SERVER['HTTP_HOST'] == '*.requester.com')
{
//Access data
else{ // unauthorized access}
}

Assuming that a user has access to sub.requester.com but not requester.com, and
assuming that sub.requster.com is vulnerable to XSS. The user can exploit
provider.com by using cross-site scripting attack method.

As a proof of concept, we hosted two applications on the same domain. The provider
CORS application is hosted on testingcors.com and another application is hosted on
pavan.testingcors.com which is vulnerable to cross-site scripting.

Shows that pavan.testingcors.com is vulberable to XSS

Image: Shows that pavan.testingcors.com is vulberable to XSS

Using this vulnerable XSS subdomain, we are able to fetch sensitive information
from testingcors.com. We injected the malicious javascript payload in the “Name”
parameter. When the page loads, the script gets executed and fetches sensitive
information from the testingcors.com.