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
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.