0

According to https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token

The protection provided by this technique can be thwarted if the target website disables its same-origin policy using one of the following techniques:

Permissive Access-Control-Allow-Origin Cross-origin resource sharing header (with asterisk argument) ...

Is that correct? How does a Access-Control-Allow-Origin=* header thwart the protection? Cookie access is not governed by Access-Control-Allow-Origin headers. An attacker can never read that cookie's content via JavaScript if they are in a different origin, am I missing something?

Also if the value is * then withCredentials is automatically false (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials)

And even if it was possible, XHR doesn't allow you to read another domain's cookie, even if successfully set (https://fetch.spec.whatwg.org/#forbidden-header-name)

Is that claim wrong or perhaps I'm missing something? Or maybe the article meant that this in combination with the other items together is needed to thwart this method?

EDIT To clarify, the Cookie-to-header-token does not include a hidden input field, just a Cookie.

0

Usually a CSRF token is available in the body of a response from the server. They're commonly inside a hidden input inside a form in an html response. If that page includes a Access-Control-Allow-Origin=* header, then any website on the internet could make a request for that page and get the CSRF token.

  • Yes, but I'm talking about the Cookie-to-header token method, there is no hidden field, just a cookie. – Eran Medan Feb 20 at 23:46
  • Oh, right. I can't see how that warning applies to that strategy either. I assume that warning was copied from another section or article about general CSRF protections. – Macil Feb 20 at 23:49
  • Yeah, looks like a copy paste error – Eran Medan Feb 20 at 23:52
  • p.s. just tried it, (permissive cors, set a CSRF token that is session based, went to jsfiddle and did an XHR with credentials to that page, since it sends credentials, it sends my session cookie, thus shows the same page I see e.g., shows the hidden field with my token like a charm, important lesson on how critical is avoiding * CORS headers, as even if you are only serving JSON, one day you'll return an HTML page and forget... wow) this is surprising as I thought * blocks withCredentials according to: developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/… – Eran Medan Feb 21 at 0:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.