corsair_scan v0.2 releases: test Cross-Origin Resource Sharing (CORS) misconfigurations

by do son · Published April 5, 2021 · Updated May 24, 2021

Welcome to Corsair_scan

Corsair_scan is a security tool to test Cross-Origin Resource Sharing (CORS) misconfigurations. 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. If this is not properly configured, unauthorised domains can access those resources.

What is CORS?

CORS is an HTTP-header-based mechanism that allows a server to indicate any other origins (domain, scheme, or port) than its own from which a browser should permit the loading of resources. It works by adding new HTTP headers that let servers describe which origins are permitted to read that information from a web browser.

CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

The most common and problematic security issue when implementing CORS is the failure to validate/whitelist requestors. Too often, we see the value for Access-Control-Allow-Origin set to ‘*’.

Unfortunately, this is the default and as such allows any domain on the web to access that site’s resources.

As per the OWASP Application Security Verification Standard (ASVS), requirement 14.5.3 states

Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the “null” origin.

How Does corsair_scan work?

Corsair_scan works by resending a request (or list of requests) received as a parameter and then injecting a value in the Origin header. Depending on the content of the Access-Control-Allow-Origin header in the response to this request, we can assert if the CORS configuration is correct or not. There are three scenarios that indicate that CORS is misconfigured:

The fake origin sent in the request is reflected in Access-Control-Allow-Origin
The value of Access-Control-Allow-Origin is *
The value of Access-Control-Allow-Origin is null

If CORS is found to be misconfigured, we check to see if the response contains the header Access-Control-Allow-Credentials, which means that the server allows credentials to be included on cross-origin requests.

Often, CORS configurations make use of wildcards, for example accepting anything under * example.com *. This means that the origin domain.com.evil.com will be accepted as it matches the given regex. To try and combat this, corsair_scan tests four scenarios:

Fake domain injection: We set the origin header to https://scarymonster.com, even if the original request doesn’t have an origin header
If the original request has an origin header (for clarity, let’s assume it is https://example.com):
- Pre-domain injection: We concatenate our fake domain to the original domain on the left. In our example, the origin will be set to https://scarymonsterexample.com
- Post-domain injection: The opposite of pre-domain, just concatenation on the right. The origin will be https://example.com.scarymonster.com
- Sub-domain injection: Sometimes the CORS configuration whitelists all the subdomains under a given domain. Although it is not a problem per-se, if one of the domains is vulnerable to XSS, then, it can be a serious problem. The origin in this scenario will be https://scarymonster.example.com