The Same-Origin Policy(SOP) restricted information sharing between applications and allowed sharing only within the domain the application was hosted on. This was a precaution to protect systems from giving up confidential information. But, with the growing usage of web-applications and microservices, there is a need to pass information from one subdomain to another, or between different domains for practicality purposes. This need might be for rendering purposes or for crucial functionality such as passing access tokens and session identifiers to another application.

With SOP in place, in order to allow cross-domain communication, developers had to use different techniques to bypass SOP and pass sensitive information. The ‘by-passing’ happened too much to a point that it became a security issue. So, in order to enable information sharing without compromising the security posture of applications, the Cross-Origin Resource Sharing (CORS) was introduced in HTML5. But, this didn’t solve the whole issue when people started using default configurations or misconfigured to cut corners or were simply unaware of its potential risks.

Learn more: How AppSec testing can make your app development easier than ever

So, as a security analyst or an engineer, it is important for you to understand how misconfigured CORS headers can be exploited. The business implications of this can be anywhere from stealing data to compromising your entire application. Understanding the risks will enable to better remediate it before a catastrophe.

WHAT IS CORS?

Cross-Origin Resource Sharing(CORS) is a mechanism that enables web browsers to perform cross-domain requests using the XMLHttpRequest API in a controlled manner. These cross-origin requests have an Origin header, that identifies the domain initiating the request. It defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed.

KEY CORS HEADERS

There are a number of HTTP headers related to CORS, but the following three response headers are the most important for security:  

THREE ATTACK SCENARIOS

  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

  1. 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. 

  1. 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. 

Shows the retrieved information from the XSS exploit
Image:
 Shows the retrieved information from the XSS exploit
 

CONCLUSION

Cross-Origin Request Site is an OWASP TOP 10 Security Misconfiguration vulnerability. In the process of enabling information sharing between sites, people tend to overlook the significance of CORS configuration. As developers or security experts, it’s very important that you are aware of this vulnerability and how it can be exploited.  

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.