1

I have a web app in which, when users request a page, a CSRF token is generated and injected into the jsp page in a hidden input field.

The same token is then sent to the server for every AJAX call in a custom header whereas, a session-state token is contained in a cookie (secure + httpOnly).

Now, since the CSRF token is something new in the webapp, if after the update the user was already logged in, and he sends a request, a Filter will determine that he's in fact logged (because of session-state token in the cookie), but a valid CSRF token is not contained in the custom header, and so the defined behavior is to log him out.

I may deal with this, by following this OWASP example. If a CSRF token is not present, I intend to send a NO-CONTENT request back and somehow provide the token.

Here's the first doubt:

Shouldn't the CSRF token not be placed in a cookie?.

Moreover they are providing a CSRF token back if it's missing in the request, which seems to me a bit of anti-secure: an attacker could have stolen the session token from the cookie, send a request, and magically receive the CSRF token back.

I therefore feel confused here.

  • Should I just put the CSRF token in the cookie along the session state token?
  • Should I avoid providing a CSRF token if none is set, but a session-state cookie exists?
  • What may an alternative solution for my case be?

Notes:

Before checking the CSRF token, I verify the origin and referer headers, as advised here.

I do not plan to implement a use-only-one-per-request CSRF token.

Although irrelevant in this context, the communication happens via HTTPS

Shurmajee
  • 7,335
  • 5
  • 28
  • 59
payloc91
  • 135
  • 2
  • 7

1 Answers1

1

There are multiple ways to address a CSRF vulnerability. The implementation that you are looking at, uses a stateless method of managing the CSRF token. This is called the double submitted cookie method. This saves you some effort if you do not wish to track the CSRF token on the server side.

From the OWASP link you shared in the question:

A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

The security risk arises when your CSRF token resides only in the cookie and nowhere else. This would not be sufficient for CSRF prevention as it would be the same thing as having another session cookie.

In the double submitted cookie implementation you just have to ensure that the token values received from the cookie and from the form parameter are the same. In case of a CSRF attack the forged request would contain the token in the cookie but the token value from the from parameter/custom header will be absent. Hence leading to detection and prevention of CSRF.

To answer your other question about returning a CSRF token if the request is authenticated but does not contain a token already. This entirely depends on the kind of user experience you want your users to have. In some cases it may be okay to redirect the user to a login page.

Let us say you do return the token in the cookie and there is a CSRF attempt. In such a case Same Origin Policy would prevent any malicious domain to gain access to the cookie value directly and hence the subsequent forged request would fail for the same reasons given above.

For additional security considerations in case of a double submitted cookie implementation:

Double Submit Cookies vulnerabilities

Shurmajee
  • 7,335
  • 5
  • 28
  • 59