Relevant (unanswered) questions I've asked on StackOverflow:
First the problem. This application involves filling out large web forms, which often take the users a significant amount of time. During this time, a user's session may expire and the user loses their work. A mechanism is needed to allow users to renew their session prior to submitting the form. See my linked questions for more detail.
The solution I have come up with, which I am questioning the security of, is as follows:
- The user logs in as normal and begins filling out a form
- The user's session expires. Since the CSRF token is associated with the session, the CSRF token is now also invalid.
- The user clicks the "renew session" button, which opens a new tab with a login page. The user's now-invalid CSRF token is also forwarded to the login page.
- The client sends their username and password (along with the old invalid CSRF token in a hidden field) to the server.
- The server checks the username and password. If they are valid, the server re-associates that CSRF token with the user's new session, making the token valid again.
- The user submits their original form (which has the original CSRF token as a hidden field). The server sees that the CSRF token matches the one given by the client at login, and accepts the form submission.
- The server issues a new CSRF token to use on the next request.
Put more simply, if the server receives a string controlled by the client during the user's initial authentication, alongside the user's username and password, is it safe for the server to treat that string as a valid CSRF token for a subsequent request from that same client? Or is there a way that this could be exploited?
It seems to me that, considering the request which sets the CSRF token is only accepted if accompanied by a valid username and password, it should still prevent CSRF. After all, if an attacker has that information, they have already compromised security. However, there may be things I have not considered; hence this question.