7

I have a very long web form that could take hours for people to complete. The problem with this is when people take too long the CSRF token expires before they're done and when they hit submit they get a 403 error.

To fix this issue I'm thinking of doing an AJAX request every hour to update the session and extend the token expiry. Are there any security concerns with doing this? Or are there any better ways of handling this situation?

|improve this question
4

There are absolutely security concerns with this; otherwise, the session timeout would be useless in the first place.

That said, there may be good reasons to disable session timeouts, but in this case, you can and should do so explicitly, and with full regard of all consequences.

To add to the solution: while I think it's already questionable to have a single form on a single web page that takes that long to fill out without saving in the meantime, with the risk of loosing the whole work when anything goes wrong (big usability issue), I think what you do want to achieve is prolonging the session (and thus the validity of the csrf token) by doing an ajax request every so often when the user is still active. So you should monitor if any form fields where changed (for example, within the last 5 minutes), and only then start the ajax request.

|improve this answer
  • With a bit of re-wording, this is a fine answer on its own. – Xander Apr 4 '16 at 16:04
  • You are correct. I had missed in the question that the session would be extended as well. I added a note about that in my answer. – Anonymous Sep 29 '16 at 12:22
2

You don't need to set an independent expiry time for the CSRF token, the token needs to be unique and valid for the current user session, when the user session will expire the csrf token expires along with the session, and then you must generate a new token. This could be a simple solution.

|improve this answer
  • So you're saying just extend the session? – jwerre Jul 1 '15 at 12:21
  • I could just ping the server on input change. That would extend the session and solve the problem. – jwerre Jul 1 '15 at 12:22
  • 1
    It's a horrible solution in my opinion :) – eurialo Jul 1 '15 at 12:23
  • ok so what is your solution? – jwerre Jul 1 '15 at 12:24
  • 1
    @jwerre if https is used on the site then there is no way for a malicious party to capture the CSRF token of a user. There should be no reason to expire the CSRF token until the session expires. "In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires" from owasp.org/index.php/… – d0nut Apr 4 '16 at 13:51
-2

See the answer by Nicolai Ehemann for a more general answer. This answer assumes that the token is being refreshed without also lengthening the session.

I see no problem with this. It is effectively the same as resetting the token when the user reloads the page. Assuming that you are using https and properly implement the ajax request and token generation, an attacker should still not know what the user token is.

The same risks apply as do when normally generating a CSRF token without ajax, because to the browser, it is basically doing the same job.

|improve this answer

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.