Blog

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 web server) 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 & Risk

A CORS misconfiguration can leave the application at a high risk of compromises resulting in an impact on the confidentiality and integrity of data by allowing third-party sites to carry out privileged requests through your website’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 toward 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 is where 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.

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.

• The victim visits another-website.com while being authenticated to your-website.com.

• another-website.com provides the victim with a malicious script that will interact with your-website.com.

• 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 modifying user settings.

• your-website.com responds to the victim’s browser with the data request and the CORS header.

• 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).

• 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 subdomain such as subdomain.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 detecting 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.