Discussion on: How not to mess up Sessions in your sensitive web apps

thomasjunkos profile image
Thomas Junkツ

Traditional sessions are simple.

You need

  • An identifier for an active session which someone posesses (say in form of a cookie)

  • A storage for current running sessions (= session data) which allows someone with a valid identifier to use just this session

Session storages work with the lookup principle (key/value): They return for any identifier what was stored (say: user's ID, first name, last name, $whatever).

If someone gives you correct credentials you give them in turn a session identifier. Everybody with this identifier has access to the ressources protected by this until the session expires or the identifier is lost.

You could cryptographically sign the session identifier if you want to feel super safe - but the benefit from that is doubted. But typically a sufficiently long enough identifier is enough.

From that said, it is clear, that for any adversary it is in his main interest to get hold of said identifier (next to credentials) in order to compromise a user.

There are additional ways of securing this:

  • using HTTPS for securing the transport
  • making sure you only hand a cookie over a HTTPS connection
  • using httponly cookies to make sure JS has no access to it
kent profile image
Khant Htet Naing(Kent) Author

Thank you for commenting, Thomas. You explained it very well. I really appreciate that.