Cross-Domain Request is a CSRF Attack? (CORS)

Question

CORS is a HTTP Suite header that “relax” the SOP. One of the CORS misconfigurations is about to reflect without reg exp the “Origin” client header into “ACAO” response header. If it happens with “ACAC:true” every cross-domain HTTP request is allowed.

If an attacker induces a victim to visit with another tab of the browser, a malicious web server with a Javascript CORS exploit; the browser triggered by exploit does a HTTP request to a vulnerable webpage and sends the output to a web server controlled by the attacker.

It happens because CORS has a misconfiguration and because the vulnerable page doesn’t have a CSRF Token.

Was this Cross-Domain HTTP request essentially a CSRF attack? If yes, it happens because there is a CORS misconfiguration and there isn’t the CSRF Token? What happens if it has a Anti-XSRF Token?

I read that CORS and SOP can’t block a CSRF attack, because the policy prevents only to access to the response on the request, but the HTTP request works anyway.

If CORS and SOP can’t block a CSRF attack, the CSRF attack could work also if the web server target is not vulnerable a CORS misconfiguration?

Answer 1

The purpose behind a CSRF attack is to cause a server side state change. For example, if a website like Facebook was vulnerable to CSRF, you would be able to post a message on the user's timeline by tricking the user and initiating a request from another browser tab. Note that in this case you do not need to read the response coming back from the server. As long as the server processes your request, the attack is successful. To answer your specific question Disabling CORS would not prevent CSRF attacks. There are other ways to protect against CSRF. Having CSRF prevention built in

CORS is supposed to be a safe way to perform cross domain communication between trusted origins. Exploiting a CORS mis-configuration issue is similar in nature to a CSRF attack (tricking the user into visiting an attacker controlled domain and sending cross domain requests) but the idea is to read (steal) sensitive data from the target domain.

A CORS misconfiguration may allow untrusted domains to make cross domain authenticated requests and read the data that they are not supposed to read. The most common scenario for CORS exploitation is a site which uses the origin sent in the HTTP request to populate the Access-Control-Allow-Origin response header. If you are lucky the application may also send back Access-Control-Allow-Credentials. This would allow you to make authenticated cross origin requests and read the responses. There are some other examples like the Originull exploit that you should look at.

Having CSRF protection for cross origin requests does not make sense. The whole idea of CORS is to securely allow cross domain requests from a whitelist of domains. Not sure how you would implement a CSRF token in this case.

Here is some additional recommended reading:

https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties

How does CSRF correlate with Same Origin Policy

Answer 2

Was this Cross-Domain HTTP request essentially a CSRF attack?

Essentially, yes, but only because you specifically disabled the checks that should have prevented it.

If yes, it happens because there is a CORS misconfiguration and there isn’t the CSRF Token? What happens if it has a Anti-XSRF Token?

There are a number of additional factors to consider:

First, not all requests are XHR requests, and therefore are not subject to CORS. The malicious page can host an plain old <form method="post" action="https://yoursite.com"> which can submit arbitrary payloads to your server (without allowing the attacker to read the result), necessitating a CSRF token. Modern browsers make this somewhat unnecessary by supporting the SameSite attribute for cookies, but not all browsers support SameSite, and some users will be on browsers that lack SameSite support essentially forever. So, CSRF tokens are still important to prevent cross-site form submissions.

Secondly, the HTTP verb matters, and can be considered an additional layer of defense. As you state...

I read that CORS and SOP can’t block a CSRF attack, because the policy prevents only to access to the response on the request, but the HTTP request works anyway.

What you describe only applies to GET requests. However, GET requests do not use a CSRF token in the first place. As long as your service correctly only uses GET for idempotent requests with no side effects, the GET request can succeed, and there is no danger as long as the malicious page is prevented from reading the result.

CORS protects other methods like POST/PUT/DELETE (that do cause side effects) with a preflight OPTIONS request. If that preflight request fails a CORS check, not only is the attacker prevented from reading the response, the actual POST request will not happen, so there is no response to read in the first place. The browse will not actually perform a POST to your service if the OPTIONS request fails.

So, in the usual case where a CSRF token is relevant (PUT/POST/PATCH/etc) a CSRF token would have prevented the CORS misconfiguration you describe from allowing arbitrary XHR and non-XHR requests from malicious domains, but only if combined with an old browser or a SameSite misconfiguration.

If CORS and SOP can’t block a CSRF attack, the CSRF attack could work also if the web server target is not vulnerable a CORS misconfiguration?

No. If CORS were correctly configured, and your service didn't use GET incorrectly, CORS would allow the (safe) GET request but prevent the attacker from being reading the result, and it would prevent POST/PATCH/etc request from being made at all.