1

Should I run the session idle timeout timer

  1. From the start of the first request to the start of the next request, or
  2. From the end of the first request to the start of the next request?

A bit of context - I have a 10 minute idle timeout on a Web API application. Some of the requests take a long time (say around 8 minutes). If I do 1., users effectively lose 8 minutes of their idle quota on these requests. If I do 2., it does not sit well with the definition of idle - the user has been (forced to be) idle since initiating the first request.

I'm inclined to 2. because of UX but definition concerns aside, is there any way 2. could be misused?

I believe the idle timeout is in place for most of the reasons as in https://security.stackexchange.com/a/54668/164690 and am ok for any answers to focus on these requirements (unfortunately, I can't find any formal requirements supporting my belief - the current system is based on a very old system, whose requirements are unfortunately lost in the annals of time. For the same reason, I'm not sure why 10 minutes and not 9 or 11). That said, I am curious as to whether there are any sort of security loopholes that can utilize 2. and not 1.

Note - I also have an absolute timeout running from the start of the session

potatopeelings
  • 111
  • 1
  • 6
  • My apologies if this is supposed to be in another stackexchange site (if at all). – potatopeelings Nov 27 '17 at 01:52
  • Please explain what do you want to achieve with the timeout in the first place and why do you choose exactly this timeout. Also please explain the behavior of your application in more detail: A browser will usually not wait 8 minutes to receive a response so you must have some mechanism to make the browser not time out the connection by itself. – Steffen Ullrich Nov 27 '17 at 04:16
  • @SteffenUllrich - I've updated the question (its a Web API application and I've added what I think are the reasons). Thanks! – potatopeelings Nov 27 '17 at 06:07
  • An HTTP API request which takes 8 minutes is a complete and utter insanity. Everything that takes more than a minute (or even less) to process should be asynchronous. What if TCP connection fails after 6 minutes? What if after 7 minutes WiFi connection drops and reestablishes? You'd better thick twice about the design of your application. – ximaera Jan 26 '18 at 07:53
  • @ximaera - the request is asynchronous and has error handlers (shows the user an error message). Why did you think it was synchronous? (so that I can update that part of the question to clarify) – potatopeelings Jan 28 '18 at 21:44
  • *"Some of the requests take a long time (say around 8 minutes)"*. It reads like an HTTP request takes 8 minutes. – ximaera Jan 28 '18 at 21:48
  • Um. it does - the JSON POST request takes 8 minutes (during which time the button that initiates the request is disabled and shows a loading icon). – potatopeelings Jan 28 '18 at 21:54
  • This way, all the concerns I've raised above apply. – ximaera Jan 28 '18 at 23:37
  • Ah yes. You're right and we're ok with that - its a just in time report generation. In most cases, it completes pretty fast (under 10 seconds or so). In the rare instances that it does take 8 minutes (a 20 year date range with all entities) we're ok for it to fail and ask the user to retry from a more stable connection. Emailing / providing the report in the site when it completes is an alternative - but the added complexity wasn't justified in our case. – potatopeelings Jan 29 '18 at 00:07

1 Answers1

1

This depends on what should be achieved with the timeout. You might timeout a session if the user did not interact with the site for some time. Or you might timeout the session if the user has not visited the site for some time, but don't timeout if the site is still open inside the browser. The first way is more secure but the second is more comfortable for the user (longer timeouts are more comfortable too). How to weight security vs. usability depends on your specific use case.

If the session timeout should be triggered based on actual user activity then it should be reset only if such activity is found, i.e. at the start of a HTTP request which was caused by activity of the user.

If the session timeout should instead be based on browser activity (i.e is the web site is still open in the browser) then it can be reset whenever data is successfully exchanged with the browser. Such successful exchange means that the web site is still open inside the browser and the the browser has network connection but it does not mean that the user is actually doing something with the site (i.e. might be away from keyboard).

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks for answering! If I understand correctly this works backward to specific 'what i want to achieve' i.e. 1 = _timeout if the user did not interact with the site_ and 2 approximates _don't timeout if the site is still open_. But if I want to timeout based on last interaction and I measure timeout from the end of the request (instead of the beginning) could this be misused (to give a possibly implementation dependent example, say, keep the session alive for more than its absolute timeout). – potatopeelings Nov 27 '17 at 22:54
  • @potatopeelings: If you want a timeout based on last interaction of the user with the site you need to reset it whenever the user interacts with the site. This means the beginning of the request (user clicks something or similar) and not the end of it (there is no user activity known to the server, only browser activity). *"...could this be misused..."* - no user interaction means that the user might be away from keyboard. This could be misused if the attacker is at the keyboard instead of the user. The larger the timeout the higher the chance of it. – Steffen Ullrich Nov 28 '17 at 05:36