Cross Origin Resource Sharing CORS Misconfiguration Impact

The Cross Origin Resource Sharing CORS standard describes new HTTP headers which provide browsers a way to request remote URLs only when they have permission. Although some validation and authorization can be performed by the server, it is generally the browser’s responsibility to support these headers and honor the restrictions they impose.

In the following post, we are describing the CORS misconfiguration issue and its Prevention.

What is Cross Origin Resource Sharing CORS ?

A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos.

Certain “cross-domain” requests, notably Ajax requests, are forbidden by default by the same-origin security policy.

Cross Origin Resource Sharing CORS defines a way in which a browser and server can interact to determine whether it is safe to allow the cross-origin request.

The web application is a saas based application in which we have option to create users and add them as client, employee and user (least permission).

There was a send email function in the web app to send attached files to your clients and There was a email field where we need to put email_id of the client Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served.

Impact

An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.

Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.

If the site specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to bypass any IP-based access controls by proxying through users’ browsers.

Attacker would treat many victims to visit attacker’s website, if victim is logged in, then his personal information is recorded in attacker’s server.

Also Read: CRLF Injection Define

Cross Origin Resource Sharing CORS misconfiguration issue

Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header.

Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource.

Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website.

Headers

The HTTP headers that relate to CORS are

Request headers

• Origin
• Access-Control-Request-Method
• Access-Control-Request-Headers

Response headers

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Expose-Headers
• Access-Control-Max-Age.
• Access-Control-Allow-Methods.
• Access-Control-Allow-Headers.

Check these two hackerone Proof of Concept report of CORS misconfiguration, it will help you to find the bug in another websites.

1. Zomato- CORS Misconfiguration Zomato POC
2. SEMrush Cross-origin resource sharing misconfig POC

How To Prevent Cross Origin Resource Sharing CORS Vulnerability Attacks

Only allow trusted sites

It may seem obvious but 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.

Avoid whitelisting null

Avoid using the header Access-Control-Allow-Origin: null. 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.

Avoid wildcards

Avoid using wildcards in internal networks. Trusting network configuration alone to protect internal resources is not sufficient when internal browsers can access untrusted external domains.

To check CORS Misconfiguration use CORSTest

CORStest is a quick Python 2 software to find Cross Origin Resource Sharing (CORS) misconfigurations.

It takes a text file as input which may contain a list of domain names or URLs. Currently, the following potential vulnerabilities are detected by sending a certain Origin request header and checking for the Access-Control-Allow-Origin response header:

• Developer backdoor: Insecure dev origins like JSFiddle or CodePen are allowed to access this resource
• Origin reflection: The origin is simply echoed in ACAO header, any site is allowed to access this resource
• Null misconfiguration: Any site is allowed to access by forcing the null origin via a sandboxed iframe
• Pre-domain wildcard: notdomain.com is allowed access, which can simply be registered by an attacker
• Post-domain wildcard: domain.com.evil.com is allowed access, which can be registered by an attacker
• Subdomains allowed: sub.domain.com allowed access, exploitable if attacker finds XSS in any subdomain
• Non-ssl sites allowed: A http origin is allowed access to a https resource, allows MitM to break encryption
• Invalid CORS header: Wrong use of wildcard or multiple origins, not a security problem but should be fixed

Note that these vulnerabilities/misconfigurations are dependend on the context. In most scenarios, they can only be exploited by an attacker if the Access-Control-Allow-Credentials header is present (see -q flag).

Usage
usage: corstest.py [arguments] infile

positional arguments:
infile File with domain or URL list

optional arguments:
-h, --help show this help message and exit
-c name=value Send cookie with all requests
-p processes multiprocessing (default: 32)
-s always force ssl/tls requests
-q quiet, allow-credentials only
-v produce a more verbose output

Example

Use of CORStest to detect misconfigurations for the Alexa top 750 sites (with Access-Control-Allow-Credentials):

Test run on top sites

Running this CORStest on the Alexa top 1 million sites reveals the following results:

Note that the absolute numbers are quite low, because only 3% of the 1,000,000 tested websites had CORS enabled on their main page and could be analyzed for misconfigurations.

This test took about 14 hours on a decent line (DSL). If you have a fast Internet connection, try to increase the number of parallel processes to -p50 or more.

Reference: 

GitHub, Portswigger, Wikipedia, Hackerone