1

I was reading this article about session tokens from Mozilla's Developer website. Historically, I've always assumed that a session token set with a blank expiry (or one set to zero) would expire at the end of a session. This seems to be backed up by John Wu's answer here: https://security.stackexchange.com/a/47419/78535

However, on the Mozilla site, they say that some browsers use session restore, where tokens are restored the next time the browser opens as if the browser was never used (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)

How then do sites make sure that session tokens are properly invalidated at the end of a session? Do they have to use a session expiry server side, where a session is expired after a period of inactivity? Or is there a more clever way of making sure the cookie is no longer accepted when a browser has been closed.

Brewer
  • 41
  • 3
  • See https://www.php.net/manual/en/function.session-destroy.php for ways of destroying the session on the server side in PHP. – mti2935 Jul 05 '21 at 18:13

1 Answers1

3

Follow the Golden Rule of web programming: Never Trust the Client.

When you send a Set-Cookie header to the client, you are asking the browser nicely if it could please store this data for you, and please only do so for this amount of time. A browser might comply with your request, or it might spray-paint the content of the cookie onto the wall of an art gallery (I kind of want to make that artwork now...)

The server must not assume that just because a request contains a particular Cookie header, it represents a browser obeying the earlier instructions from Set-Cookie. Like any other input from the client, the value must be treated with suspicion.

Even if the browser implements things correctly, the user might circumvent that behaviour. In the case of browser sessions, many users leave computers logged in, with dozens of browser tabs open, for days and weeks at a time, which makes the concept of a "session" fairly meaningless.

How then do sites make sure that session tokens are properly invalidated at the end of a session?

The session token needs to be invalidated independently of the cookie; there are two general approaches:

  • The session token is tracked on the server, in some form of data store (as simple as a directory on disk, or as elaborate as a distributed highly-available key-value database). The server can track logout events and expiry times in that data store, and reject any session token that is invalid.
  • The session token is a signed message containing its own (usually quite short) expiry time, such as a JWT. The server validates the signature first; if that's valid, it validates the expiry time; if that's valid, it might also check a list of explicitly revoked tokens (for logout or user deletion); only then is the token accepted.
IMSoP
  • 3,790
  • 1
  • 15
  • 19
  • +1, but honestly, the first line extends way beyond just *web* programming. For any system where access to the client isn't extremely tightly controlled, the client can't ever be trusted. Also might be worth mentioning that, with JWTs or other self-expiring tokens, you usually have some mechanism to refresh them (if the session is still valid) using a value tracked in server state (a refresh token), although there are other options – CBHacking Jul 06 '21 at 08:08