CORS Misconfigurations

How CORS Works

Long Explanation

Usually Same Origin Policy denies XMLHTTP requests to other domains. CORS allows those with Access-Control-Allow-Origin (the remote host must add this header).

It can also allow you to add credentials with Access-Control-Allow-Credentials (ACAC).

ACAO (access control allow origin) allows you a couple of options:

• A single domain name (google.com)

• A wildcard (*)

  • In other words, all domains.

  • But ACAC doesnt work when you the allowed origin is *

• null

  • Null origins are given by local files

  • You can also get a null origin from an iframe sandbox,

  • Basically the null origin is a better version of * for an attacker, because it allows for ACAC and it can be done from any website.

As a web developer, because you can only trust a single domain name, then if you have multiple domains you want to trust, you will have to dynamically generate ACAO domains based on user input.

Summary

So basically, ACAC allows for very CSRF-like behaviour via ACAO misconfigurations.

Also you can do some stuff without ACAC.

Taken from Exploiting CORS Misconfigurations For Bitcoins And Bounties by James Kettle.

Exploitation

ACAC is Enabled

If any origin is allowed, then you can just make a request from your site.

If twitter.com checks that the origin starts with twitter.com, you can do it from twitter.com.evil.com.

If they validate the end and forget to check that it starts with the dot, then you can just do it from nottwitter.com

If they allow null, then you can use iframe sandbox to get null origin.

If they allow *.site.com, then if they allow http:// connections, then that’s still exploitable. For exploitation details watch this video at around 22 minutes or read the blog post.

And even if they don’t allow *.site.com, you can still do it with XSS, subdomain hijacking. Maybe corporate proxies like McAfee Web Gateway if it’s there.

ACAC Not enabled

There was a case where Jetbrains’ IntelliJ had some CORS misconfiguration (ACAO enabled) and you were able to get SSH keys and even RCE through the IntelliJ server running on localhost.

Vary Origin

Vary: Origin is used if you want to have more than one allowed origin. It indicates that the response is dependent on the origin, and prevents caching of responses. If it is missing, then you may be able to exploit caching related vulnerabilities.

Making “unexploitable” XSS exploitable

Unexploitable usually vaguely means something like - the string in a header (like X-User) gets reflected, but there’s no way to make the user’s browser send that header.

Thanks to CORS, you can send that header cross-domain using a javascript request.

But, unless you specify Vary: Origin, it may be cached in the browser. And then, when you take the actual user there, he will get the cached XSS.

Server side cache poisoning also possible.

Discovering Dynamically Generated CORS Headers

You have to look separately for dynamic generation of CORS headers. Say you’re on Google.com. When you make an XMLHTTP request with origin evil.com, then you will not get the headers. If you make it with origin google.com, you will get the headers.