1

I have the following questions regarding CSRF, SOP and CORS.

  1. Does CSRF tokens only protect form submission with either POST or GET methods? Is this just a "common practice" (regarding the fact that only form submissions are vulnerable like for example POSTing a request to transfer funds in a web banking site)

  2. Is CORS only available (bypasses SOP) when requesting content with a GET method and not with POST? If a form is protected with CSRF token then there is no point in reffering to CORS to make such a request (meaning to submit the form from a different domain) due to the fact that even with CORS enabled there is a CSRF token protecting that content (even if this is not a typical use case of CSRF token).

  3. Is CORS based on checking the origin header due to the fact that the browser of the victim cannot be tricked into spoofing the Origin header? While cURL enables us to spoof headers, in this particular attack the browser of the victim cannot be fooled?

I have read various posts regarding the above but I would love a clearer explanation. For instance I have read that:

However, resource loading from other hosts like images, scripts, stylesheets, iframes, form submissions etc. are not subject to this limitation

What confuses me I think is that most threads regarding CSRF token only elaborate only on examples with forms and posting data with POST method to a server and don't elaborate on the greater picture.

closed as too broad by Anders, Overmind, Josef, Tobi Nary, Rory Alsop May 25 '18 at 10:36

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Hello! Please only post one question per question. I think #1 and #2 are sort of related, so perhaps they fit in the same question. But I think you would be better of if you edit your question to remove #3, and instead ask it in a different question. – Anders May 14 '18 at 10:52
  • You are correct, #1 and #2 are related; I think I will leave #3 intact because I would love if someone could elaborate in all the 3 concepts in one place (all three of them can be addressed with a good example I think). – XII May 14 '18 at 10:54
  • the browser knows where the response came from, it doesn't need the origin header explicitly, though i'm sure they say the same thing anyway. you can POST from another site if that site is given the csrf token, and CORS allows that POSTs to provide a response to the script on the 3rd site. CSRF is likely only needed for GET, it's used w/POST as defense in depth in the case of XSS – dandavis May 14 '18 at 20:31
5

Based on what you ask I think you are confusing concepts a bit:

  • CSRF is a method to execute an authenticated action cross-site, i.e. triggered by an attacker but executed with the authentication of an already logged in user due to the automatic sending of existing session cookies or basic authentication credentials. CSRF is only about executing the action and does not care about reading the result.
  • In the context of CSRF CORS is about controlling which requests can be submitted by the browser to the server in the first place using the XMLHTTPRequest or fetch API. It does not restrict the sending of simple requests, which are requests which could be created without XMLHTTPRequest or fetch by embedding a resource, submitting a form etc. It only restricts which non-simple requests (i.e. requests with custom method, custom header...) could be sent cross-site by having a pre-flight requests before these non-simple requests to check the CORS policy of the site to see if the real request is allowed.
  • CORS is not the single policy which covers all things related to any kind of cross-site requests but only covers a specific subset.

With this in mind:

  1. Does CSRF tokens only protect form submission with either POST or GET methods?

A CSRF token is essentially a secret which the attacker cannot guess. It can be used for any kind of requests. But given that with non-simple requests the CORS policy would be checked anyway it does not really add value for such requests. Thus when using XMLHTTPRequest or fetch often a non-simple request is enforced by adding some custom header so that no (more complex) CSRF token is needed.

  1. Is CORS only available (bypasses SOP) when requesting content with a GET method and not with POST?

CORS has nothing to do with GET or POST but is about non-simple vs. simple requests. Both kind of requests can use GET or POST, although non-simple requests could also use custom methods.

  1. Is CORS based on checking the origin header due to the fact that the browser of the victim cannot be tricked into spoofing the Origin header?

CORS is not based on checking the Origin header at all. The CORS policy is enforced by the browser and not the server. There are cases where checking the Origin or Referer header is relevant though: like when protecting against CSRF without a CSRF token or when restricting WebSockets access. But these cases are not covered by CORS, i.e. CORS is not the only thing which cares about cross-site requests.

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