Web Sessions

tags : Web Authentication, Cookies, JWT

FAQ §

What it is §

After we verify the user is who they say they are

• Instead of a predictable user_id (See JWT bad default))
• We’re sending the client a completely random session id that is impossibly hard to guess.
• The ID has no further meaning, and doesn’t decode to anything.
• This is sometimes called an opaque token
• We usually send it over in a Cookie (Client side)

Where is it stored server side? §

• Previously store in memory or in local filesystem
• But these days, webservers and their fs is mostly ephemeral
• So ppl prefer storing session id(s) in Redis or similar external store

Access Control §

• See IAM (Identity and Access Management)
• We can maintain a table linked to each user, where the access/role of the user is defined
• That way we can use the session token to do access control as needed

Anatomy §

Types §

Anonymous sessions (pre-auth) §

• Keeping track of anon users, eg. keep track of language choice etc.
• A complementary recommendation is to use a different session ID or token name pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

User sessions (post-auth) §

• Signifies that the user is infact the user

Properties §

• session ID is a name=value pair.
  • Good practice is to set name to just id
  • The value should be complete gibbrish from the start to the final encoding.

Security §

Attacks §

Session Hijacking §

• Targeted

  Attacker’s goal is to impersonate a specific (or privileged) web application victim user.

• Generic

  Attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

Session fixation §

• In a session fixation attack, the attacker fixes the user’s session ID before the user even logs into the target server, thereby eliminating the need to obtain the user’s session ID afterwards
• Regeneration of SessionID after any Privilege Level Changes is a MUST
  • Eg. password changes, permission changes, or switching from a regular user role to an administrator role, anon user to registered user auth etc.
  • In these cases, old sessionID should be destroyed

Other attacks §

• Interception
• Prediction
• brute-force

Best Practices §

Content Caching §

• Must use Cache-Control HTTP headers
• Private or sensitive data exchanged within the session through the web browser cache, these should be invalidated
• Session-ID should itself NEVER be cached. Highly recommended to use the Cache-Control: no-cache="Set-Cookie, Set-Cookie2" directive

Validating session ID §

• SessionID coming from any client should be considered un-trusted by the server. i.e validate and verify