3

OWASP recommends setting session timeouts to minimal value possible, to minimize the time an attacker has to hijack the session:

Session timeout define action window time for a user thus this window represents, in the same time, the delay in which an attacker can try to steal and use a existing user session...

For this, it's best practices to :

  • Set session timeout to the minimal value possible depending on the context of the application.
  • Avoid "infinite" session timeout.
  • Prefer declarative definition of the session timeout in order to apply global timeout for all application sessions.
  • Trace session creation/destroy in order to analyse creation trend and try to detect anormal session number creation (application profiling phase in a attack).

(Source)

The most popular methods of session hijacking attacks are , packet , and compromise via , but these are all real-time attacks on the current session.

Once hijacked, the attacker will be able to prevent an idle timeout (via activity), and I would consider any successful session hijack a security breach anyway (unless you want to argue how much larger than zero seconds of access an attacker can have before it actually counts as an actual breach).

If the original method of getting the session token can be repeated, this seems to further limit the usefulness of a timeout -- a 5-minute window that can be repeated indefinitely is effectively not limited.

What real-world attack exists (even theoretically) where a session timeout would be an effective mitigation? Is session expiry really just a form of ?

Community
  • 1
gregmac
  • 523
  • 1
  • 3
  • 14
  • Have you check the [OWASP page detailing such attacks](https://www.owasp.org/index.php/Session_hijacking_attack)? – Filipe dos Santos Jan 14 '20 at 19:53
  • If an attacker gets the session cookie value for another user, theoretically they may be able to see another user's data. – Filipe dos Santos Jan 14 '20 at 19:56
  • [OWASP Juice Shop application](https://www.owasp.org/index.php/OWASP_Juice_Shop_Project) has examples of such attacks. – Filipe dos Santos Jan 14 '20 at 19:57
  • @FilipedosSantos I'm not disputing session hijacking as a valid attack -- it absolutely is. I'm questioning eactly how expiring sessions helps mitigate session hijacking (or any other type of attack). – gregmac Jan 14 '20 at 20:00
  • If the session has an expiration timeout of 5 minutes, in the worst case scenario, even if the attacker acquire a valid session value, it will only be valid for 5 minutes. Without a timeout the attacker has unlimited access to another user's data. – Filipe dos Santos Jan 14 '20 at 20:02
  • @FilipedosSantos In many (probably most) systems, 5 minutes of unauthorized access is enough to escalate their access and/or do permanent damage. For example, they could create another user account for themselves, reset the account password, generate OAuth tokens, etc. They could also scrape data/documents (using a crawler to mirror everything quickly), or modify or delete data. And this assumes that the attacker's use of their session doesn't affect the session timeout. – gregmac Jan 14 '20 at 21:03
  • The whole security-by-timeout mindset is just way too close to being security-by-obscurity for my liking. If you're saying 5 minutes is acceptable, but unlimited is not, then where is the line -- exactly how many minutes of access is it ok for an attacker to have? My take is *no* amount of time is acceptable, and it's from that line of thinking that I'm trying to understand what real security session timeouts provide, if any, and specifically what (type of) attacks are mitigated by timeouts, if any. – gregmac Jan 14 '20 at 21:10
  • Well, if there is no timeout, once the security session is acquired the attacker has unlimited access time to the system... Timeouts are just another security mechanism. It's obvious that in a perfect world the attacker would never even acquire the security session. The world is not perfect. – Filipe dos Santos Jan 14 '20 at 21:15
  • We can even consider an insider that willingly records the client-side traffic and then send it to the attacker... It will always depend on your threat model, and the risks you are willing to accept, or not. – Filipe dos Santos Jan 14 '20 at 21:17
  • @gregmac I agree that there seems to be little protection, especially when timeouts/expiry can be postponed in many cases if you are already authenticated. – multithr3at3d Jan 14 '20 at 22:38
  • I guess it helps the user that logs into their banking account from a public computer and forgets to log off... But that's already a poor practice in the first place and timeouts are only effective if the attacker isn't quick enough. – multithr3at3d Jan 14 '20 at 22:39

1 Answers1

1

It prevents damage from a very common and low tech attack: device theft.

If my laptop walks away while i'm in the potty, I'd rather the thief have just 5 mins to flee and hide and start hacking than my online access being available to the more savy fence it's pawned to hours, days, or weeks later...

dandavis
  • 2,658
  • 10
  • 16
  • But if the session can be refreshed or prevented from timing out, you still lose. – multithr3at3d Jan 14 '20 at 22:35
  • @multithr3at3d: true, but regardless, i stand by "I'd rather the thief have just 5 mins". There's a lot more drug addicts looking for a quick buck than covert operatives waiting for just the right moment to strike a specific target. – dandavis Jan 14 '20 at 22:38
  • I agree but even better: you probably were done with most websites 5 minutes before having your laptop stolen. So the thief had no opportunity to hack most of your online accounts. In addition, the “screen lock after 5 minutes of inactivity” can also be considered a session timeout. This prevents an idle home or work computer from being misused 5 minutes after you take a break. – Darrell Root Jan 15 '20 at 03:18
  • So let's be clear that this about session timeout, and not automatic device locking The important distinction is with a lock, after authenticating you pick up where you left off. Web applications session timeouts, for example, might restore you to the last page you were on, but not exactly what you were doing, not multiple tabs, and any unsaved work you had is lost. If lock screens worked the same way most application session timeouts work, they'd log you out entirely (forcibly closing all applications). – gregmac Jan 16 '20 at 15:58
  • To deal with device theft, for the session timeout to be effective it has to be shorter than the *minimum* time an attacker would take to obtain the session keys. If the device is locked but not encrypted, this might be what: 5 minutes? If the device is encrypted, barring some design flaw or cryptography breakthrough, probably thousands of years. If the device is unlocked at time of theft, it's maybe 1 minute. So in the security-vs-convenience tradeoff, timeouts >1 minute are providing security against only 'slow' attackers while authenticating multiple times a day gets inconvenient quickly. – gregmac Jan 16 '20 at 16:14