Client Side Vulnerabilities / Cross-Origin Resource Sharing: Arbitrary Origin Trusted

Description

Cross-origin resource sharing (CORS) is a browser mechanism which enables controlled access to resources located outside of a given domain. It extends and adds flexibility to the same-origin policy (SOP). It also provides potential for cross-domain based attacks, if a website's CORS policy is poorly configured and implemented. CORS is not a protection against cross-origin attacks such as cross-site request forgery (CSRF).

Risk

The common exploitation scenarios can be described by the following steps:

1. An attacker sets up a malicious website hosting JavaScript code, which aims to retrieve data from a vulnerable web application.
2. The attacker entices the victim to visit the website using phishing or an unvalidated redirection in the target application.
3. The JavaScript code is then loaded in the victim browser and performs silent cross-domain authenticated requests to the target application to steal data and store it.

Although the risk increases when the CORS policy allows the usage of requests with credentials, there can be situations where a simple origin that is not properly validated can have a big impact.
Attackers often leverage these issues to perform advanced attack scenarios, which can lead to the takeover of application user accounts or the execution of arbitrary modifications in the target application on behalf of the victim user.

Solution

If a web resource contains sensitive information, the origin should be properly specified in the Access-Control-Allow-Origin header. Origins specified in the Access-Control-Allow-Origin header should only be sites that are trusted. In particular, dynamically reflecting origins from cross-domain requests without validation is readily exploitable and should be avoided.

The usage of the header Access-Control-Allow-Origin: null should be avoided. Cross-domain resource calls from internal documents and sandboxed requests can specify the null origin. CORS headers should be properly defined in respect of trusted origins for private and public servers.

In addition, the usage of wildcards in internal networks should be avoided. Trusting network configuration alone to protect internal resources is not sufficient when internal browsers can access untrusted external domains.

CORS defines browser behaviors and is never a replacement for server-side protection of sensitive data - an attacker can directly forge a request from any trusted origin. Therefore, web servers should continue to apply protections over sensitive data, such as authentication and session management, in addition to properly configured CORS.