Endless session: any security risk?

Question

A legacy app I'm working on let the user fill in a ton of questions and save the answers in a batch at the very end of the questionnaire. The process is lengthy and a typical user may go through a timeout at some point.

The team has come up with the idea of an endless session to bypass that problem. After some Googling I found out many articles explaining how to increase the timeout; however I didn't come across articles exposing the risk of such practice. At first sight I find reasonable to set a timeout.

My questions are:

• Do you think that an endless session may open up a security risk?
• If so what are the typical risks incurred by that practice?

Answer 1

The main risk is that the session identifier effectively becomes the password if it never expires. Anyone with access to the session identifier could record this offline, and then use this at a later time to login to the application. For example, somebody could copy the session token from the cookie with brief access to a user's machine.

A mitigation for this is to routinely rotate session identifiers. Maybe you could have an AJAX request that fires off every 10 minutes and gets a new token for the current session - even with standard session expiration times (e.g. 10-20 minutes), this would be enough to keep the session alive so that it does not time-out before the form is submitted.

Brute forcing is not an issue: As long as the session identifier has enough entropy, then there is very little risk of this being brute forced. OWASP guidance here on selecting a strong method for session identifier generation.

More on the performance side than security side is that if you're storing objects in memory for each session, then eventually memory will fill as the number of sessions increase.

Another risk with long sessions is that any CSRF or XSS vulnerabilities have a long exposure time for exploitation. A short session timeout would mitigate any attack if the user visited a malicious site targeting your app, because the user would not be authenticated. Even with persistent login, this would be mitigated if you had a long term "refresh token" with a short term (i.e. session) "access token" if your site was sufficiently locked down (e.g. it only allows a request with CSRF protection itself to exchange a refresh token for an access token).

For example if there was an CSRF vulnerability:

[User]   --> [Attacker's Site]                          --> [Your site]

Browser  --> Malicious Page builds form for your site   --> Submits form via AJAX

With an endless session timeout, this attack will succeed if the user has ever visited your site with their browser.

However if you had two session tokens: A refresh token and an access token and you required an access token to submit the form, this would prevent the attack. As the access token can only be retrieved by a same-site request, making sure that the handler for this request is sufficiently protected against CSRF would mitigate other vulnerabilities that may be present on your site.

Therefore if you must make the session infinite, use a different token that must be exchanged in order to authenticate with your website. See this post for how to implement "remember me" functionality (aka our refresh token). The drawback is that you must implement the refresh token to access token logic yourself and require that the user must re-send any requests again with the access token (which can be implemented using client-side logic with JavaScript).

Answer 2

The main reason sessions have a time out is to being able to delete any server-side stored data associated to the session at some point. Otherwise your session storage would just always grow and you would never be able to remove any of that stored data at some point.

Granted, the longer a session lasts, the more likely an attacker may be able to guess a session’s ID and possibly hijack it. But that can easily be mitigated by changing the session’s ID now and then.