Relevant (unanswered) questions I've asked on StackOverflow:

For reference, I am working in a legacy application, that also must work on browsers with JavaScript disabled, so between those two constraints the easier/better solutions to this problem are unavailable to me. However, I am trying to evaluate if the following solution provides adequate security (understanding that the user experience is less than ideal).

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:

  1. The user logs in as normal and begins filling out a form
  2. Users without JavaScript see a message indicating when their session is set to expire, with a button that will open a login page in a new tab to allow them to renew their session before clicking the form's submit button.
  3. The user's session expires. Since the CSRF token is associated with the session, the CSRF token is now also invalid.
  4. 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.
  5. The client sends their username and password (along with the old invalid CSRF token in a hidden field) to the server.
  6. 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.
  7. 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.
  8. 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.


1 Answer 1


After a lot of thought and research, I thought of an exploit to this method: evil.com hosts a phishing website with a form set to post an attacker-controlled "old" CSRF token to the session renewal endpoint. The user logs in like normal on the session renewal endpoint. Now the CSRF token has been set to an attacker-controlled value. Then the attacker can proceed with a normal CSRF attack. Basically, the attacker has to do not one but two CSRF attacks, but it's exploitable nonetheless.

So, bad idea, don't do this. For new code, obviously there would be no reason to do this anyway, there are better solutions. Jury is still out on what to do instead for my particular situation where those solutions would require basically re-writing thousands of forms, but regardless this is not the way.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .