Cross-Origin Resource Sharing (CORS) misconfigurations have slowly become one of our most common findings throughout our penetration testing engagements. The risk to the organization is often difficult to explain due to the complexity of the attack. Generally, the complexity of an attack lowers the overall risk – but not with CORS.

What is Cross-Origin Resource Sharing (CORS)?

Before diving into CORS, you must have a primer on Same-Origin Policy (SOP). SOP is used as a security mechanism in all browsers to ensure that only requests being received from the same origin (e.g., your webserver) are allowed. In other words, your-website.com cannot receive requests from another-website.com.

There are situations where you need to have api.your-website.com interacting with your-website.com. In these instances, CORS needs to be enabled to share the resource across your origin.

Impact and Risk

A CORS misconfiguration can leave the application at a high-risk of compromise resulting in an impact on the confidentiality and integrity of data by allowing third-party sites to carry out privileged requests through your web site’s authenticated users such as retrieving user setting information or saved payment card data.

On the other hand, the risk is low for applications that deal with public data and require that resources are sent to other origins. The configuration could be expected behaviour and it would need to be up to the penetration tester to identify the appropriate risk and the organization to understand and mitigate, or accept the risk.

Technical Trenches

This section is geared towards application developers or system administrators who are seeking to understand why CORS vulnerabilities exist, how they work, and how to properly mitigate them. For those not looking to get deep in technical details, you can skip to the Remediation section.

Types of CORS Misconfigurations

CORS contains two main components that when misconfigured can pose a significant risk to any web application. The two components are:

  • Access-Control-Allow-Origin – (ACAO) Allows for two-way interaction by third party websites. This can be an issue for requests that modify or pull sensitive data.
  • Access-Control-Allow-Credentials – Third-party websites can carry out privileged actions. Think of this as an attacker conducting changes that only you, the authenticated user, should be able to.

The types of misconfigurations can vary depending on the deployment. Below are the most common configurations and their corresponding risks.

TypeAccess-Control-Allow-OriginAccess-Control-Allow-CredentialsRiskReasoning
Allow all origins*TrueHighThe worse possible situation and is outlined in the CORS Attack Scenario section below. Essentially disables the Same-Origin-Policy.
FalseLowData will not be possible. The browser will not process responses that were from an authenticated request. This configuration is typically used for public APIs where limiting the ACAO is too cumbersome.
Allow subdomains*.your-website.comTrueMediumWhile this is better than a full wild-card, it still allows for CORS exploitation if any of your subdomains are vulnerable to Cross-Site Scripting or Cross-Site Request Forgery.
FalseLowEven if your subdomains are exploitable through Cross-Site Scripting, attackers would not be able to obtain authenticated data. Look into whitelisting instead of a subdomain wildcard.
Post domain and pre domain wildcardyour-website.com.evil.com

notyour-website.com
TrueHighThis scenario is considered high because an attacker can identify a vulnerability in the way your origin header is being validated and create similar matching domains that will by-pass your CORS.
FalseLowData will not be possible. The browser will not process responses that were from an authenticated request. However, consider looking into how you are validating the origin header so that a pre domain is not possible
Null allowednullTrueMediumIn many development languages, nonexistent headers are represented by the “null” value. It implies that “null” in the “origin” header would not be blocked from this “origin.” This was the basis for a Facebook exploit in 2016. For more information, visit https://www.bugsec.com/wp-content/uploads/2016/12/Blog-Post-BugSec-Cynet-Facebook-Originull.pdf
FalseLowData will not be possible. The browser will not process responses that were from an authenticated request. This configuration is typically used for public APIs where limiting the ACAO is too cumbersome.

CORS Attack Scenario

Allowing arbitrary origins with the ability to request credentials (HTTP authentication request headers and cookies) effectively disables the Same-Origin Policy in place and allows any website to issue authenticated requests to your web application. An attacker could configure a rogue site (www.malicious-site.com) and use a phishing campaign to direct your users to it. If a user is authenticated to your site, www.malicious-site.com can make API calls to your site as the authenticated user. The sensitive data would then be exposed to the attacker. The image below helps explain the attack.

Figure 1: CORS Attack Scenario

The narrative below will assist in explaining each flow item.

  1. The victim visits another-website.com while being authenticated to your-website.com.
  2. another-website.com provides the victim with a malicious script that will interact with your-website.com.
  3. The victim executes a malicious script that issues a request to your-website.com. The request can be crafted to complete a sensitive task such as modify user settings.
  4. your-website.com responds to the victim’s browser with the data request and the CORS header.
  5. At this point the CORS header will be checked to determine whether the data could be sent to another-website.com. In this scenario, CORS is allowed with authentication (access-control-allow-credentials: true).
  6. The data is sent from the victim’s browser to another-website.com.

With CORS limited to only specific web applications or APIs, the fifth call in the flow would be rejected and the browser would block the script from reading any of the response data. The scenario above is the worst-case scenario and one we see too often while conducting penetration testing against institutions that deal with sensitive information.

Remediation

To mitigate the risk of CORS, we always recommend whitelisting your Access-Control-Allow-Origin instead of wildcarding. Using a wildcard prefix such as *.yoursite.com makes it more difficult for the attackers given they would need to find a vulnerability (such as cross-site scripting or cross-site request forgery) to issue the cross-origin request. However, it is frowned upon because it does not provide the critical need-to-know security control. With whitelisting, the scope of your Access-Control-Allow-Origin will be limited to only the sites that deal directly with your primary site or API and exclude any of your sites that do not.

How Can We Help

The Packetlabs team is composed of highly trained and experienced ethical hackers that focus and excel at detection and exploiting advanced vulnerabilities that are often overlooked and go undetected. Our team members have some of the highest regarded training when it comes to penetration testing including the Offensive Security Certified Professional (OSCP), Offensive Security Certified Expert (OSCE), GIAC Web Application Penetration Tester (GWAPT), and GIAC Exploit Researcher and Advanced Penetration Tester (GXPN) certifications. Contact us to learn more about how we can help.