Does a proper CORS setup prevent CSRF attack?

If CORS is properly setup on a server to only allow a certain origins to access the server,

Is this enough to prevent CSRF attacks?

To be more specific, it is easy to make the mistake of thinking that if evil.com cannot make a request to good.com due to CORS then CSRF is prevented. There are two problems being overlooked, however:

1. CORS is respected by the browsers only. That means Google Chrome will obey CORS and not let evil.com make a request to good.com. However, imagine someone builds a native app or whatever which has a form that POSTs things to your site. XSRF tokens are the only way to prevent that.

2. Is it easy to overlook the fact that CORS is only for JS request. A regular form on evil.com that POSTs back to good.com will still work despite CORS.

For these reasons, CORS is not a good replacement for XSRF tokens. It is best to use both.

No!

CORS enables sharing between two domains where XSRF is attacking method that does not depend on CORS in anyway.

I don't understand what you mean by "CORS is properly setup" but when attacking with XSRF, browser don't ask for CORS headers on server.

CORS is not security :)

No.

The Same Origin Policy (which CORS allows you to punch selective holes through) prevents third party sites from masquerading as a user in order to read (private) data from another site.

A Cross Site Request Forgery attack is when a third party site masquerades as a user to submit data to another site (as that user). It doesn't need to read the response back.

Maybe

Man this is a tough one, and it's far more complex than the others have provided for. So "maybe"

First, CORS is intended to "relax" same-origin-policy which is a default that prevents a specific type of CSRF attack. But, same-origin doesn't apply on all kinds of requests.

> So the longer the session needs to time out and the more the user surfs around untrusted sites, the higher the risk is to pop onto one with a CSRF attack on it. Any tag which fires a request to an external resource can be used to perform a hidden CSRF attack – including images, link tags, some meta tags, embed and object tags and so on. Same goes for attributes which load background images or similar. You can even check if you site has been validated by someone if you replace the DTD file in the very header of the applications markup with a resource on your servers – that’s CSRF too. source

For an example of that, check this..

> <img src=victim.bank/check.png?account=...>; to get a check photo from a vulnerable bank site, without generating origin headers or preflighted requests. [...] The photos will be displayed, and the attackers can get the photo data using Javascript and send them back. source

However, at least one source suggests that perhaps in the future web servers will return images with Access-Control-Allow-Origin (CORS) headers on images that will stop browsers from rendering the image. This will prevent CSRF-GET attacks of this sort..

> If the browser checks the Access-Control-Allow-Origin header in the response and refuses to display it, it will be an effective defense. source

Proper CORS Setup

The modern browsers try to prevent the Cross-origin request forgery attack with a security mechanism aka SOP (Same Origin Policy).

The CORS settings is going to open some restrictions of the SOP and relaxing that.

I would Interpret The Proper CORS Setup to having :

• a browser with SOP feature
• allow cors headers to not be * or <request-origin-host> (just being the hosts which are trusted)

SOP Restrictions

if any page requests for cross-origins, there are 3 policies:

1. write-request like: link, redirects, xhr, form submitions (allow) (Rule 1)
2. embeding-request like: <script>, <link>, <img>, <video>, <audio>, <object>, <embed>, @font-face, <iframe> (allow) (Rule 2)
3. read requests (disallow) (Rule 3)

Among the above the first option (write-request) are subject to abuse for cross site request forgery.

The SOP mechanism just ALLOWED these write requests

Why?

• for backward compatibility with the existing websites
• convenient development & usage (just think if there exists a complex solution for a redirection what would happened!!! )

The only help that the Browser SOP does for this step is to send a pre-flight request for the resource-changing (POST/PUT/...) XHR requests

note: in future steps it will helps more than this

in the pre-flight request, the server sends the CORS Allow Header and browser finds out that if the resource changing request is allowed or not.

for example: if there is a form with post method which change a resource on server, the CORS Allowance Header will get received from server, but resource on server already has been changed. (antidote after sohrab's death )

> SOP will prevent CSRF attack on xhr requests & not the > application/x-www-form-urlencoded requests

• there can be a form on evil.com or an script can append a form in DOM and automatically sending that.

or the xhr preflight it self may not prevent as we expected because:

• in some browser it can be disabled because of performance (not having 2 requests)
• if Origin header not set
• Server may allow *
• some bugs on preflight request expose the functionalities ...

CSRF-Token Mechanism

CSRF token can be used on both form and xhr requests.

> CSRF-token mechanism prevents the CSRF attack if only if CSRF Token > not exposed to cross-origin malicious scripts

but this scenario can be imaginable that: an script on malicious website:

• first request for the form (aka edit form or delete form) & get the token
• then send the token with application/x-www-form-urlencoded or xhr

SOP Supports CSRF-token

I have mentioned that SOP Restricts The Read request. and only allowed the read requests which are embeded.

so SOP will prevent the CSRF-token to get exposed by an malicious script (getting the form & creating a fake form with the token) if:

• Proper CORS Setup
• the form cannot get embedded

TL;DR

The SOP mechanism (with Rule #1) (Proper CORS setup) can prevent only CSRF xhr (can have some flaws in implementations) (canot protect all scenarios)

The CSRF-Token can protect CSRF Attack if the token hasnt get compromised

The SOP mechanism (with Rule #3) can protect CSRF-token & CSRF-token protect users from CSRF-attack

We should make attention to not compromise the CSRF-token with embedded resource Rule (Rule #2). (mostly iframe abuse)

MDN How to block cross-origin access

> * To prevent cross-origin writes, check an unguessable token in the request — known as a Cross-Site Request Forgery (CSRF) token. You must > prevent cross-origin reads of pages that require this token. > * To prevent cross-origin reads of a resource, ensure that it is not embeddable. It is often necessary to prevent embedding because > embedding a resource always leaks some information about it. > * To prevent cross-origin embeds, ensure that your resource cannot be interpreted as one of the embeddable formats listed above. Browsers > may not respect the Content-Type header. For example, if you point a >

Actually CORS does contribute to security. CORS helps a lot in relation to XSS and CSRF attacks between different hosts. If a website has an XSS vulnerability and the attacker wants to use it to send a malicious request to another webpage through xmlhttprequest, thanks to CORS he is not going to be able to.