Cookie and Session

Junghoo Cho

cho@cs.ucla.edu

HTTP: Stateless

• HTTP is a stateless protocol
  • Every request can be handled independently of others
• Q: How does a Web site “remember” a user and customize its results?
  • Q: How do they know that two requests are from the same user?
• Idea: “Embed” a unique identifier in every request from a user

Cookie: Key Idea

• Cookies allow a server to ask a client to remember "name=value" pairs and send them back in all future requests

Setting Cookie

Set-Cookie: username=john; expires=Wed, 21 Oct 2031 07:28:00 GMT;

• Ask client to “set” the cookie username=john
• expires: expiration time
  • By default, cookie becomes “transient” (= session cookie) and is sent back only during current browsing session
  • expires makes cookie “persistent” until expiration
  • Setting expires to past “erases” the cookie
• path and domain
  • By default, cookie is sent in all requests to the same server
  • This can be adjusted by setting to a specific path and/or domain
  • Example: path=/cs144/; domain=ucla.edu;

Sending Cookie Back

Cookie: username=john

• In all future requests to the specified domain and path, client add the Cookie header:
  • From the cookie, server knows the requests are all from the same client

Same-Origin Policy

• Client sends the cookie only to the domain from which it was obtained
  • No cross-domain cookie exchange is allowed
• Q: Why same-origin policy?
• Q: Can we use cookie(s) to identify a user across multiple domains?

Tracking Users Across Domains

• Q: Given same-origin policy, is it possible to track a user’s requests across multiple domains?
• Q: But Google/facebook/Amazon… does it. How?

Third-Party Cookie

• A wants to track users across its partner sites B’s
• Ask partner B to include a (tiny) image from A in their pages
  • When browser access a page from B, it also sends a request to A (to download the image)
  • The request to A contains Referrer header (with B’s URL) and cookies from A
    • Third-party cookies
• A knows all URLs that users visited on partner site B

Cookie is Unsafe

• Cookies can be stolen (cookie theft)
• Cookies can be tempered with by the client (cookie poisoning)
• Be very careful about what we store in cookie

Securing Cookies

• secure; attribute
  • With secure; attribute set, the cookie is sent back only over https
  • Protects against cookie theft
• Signed cookie
  • Secret-key encrypted signature added to the main cookie data
• Attaching expiration date
  • Make sure cookie expires after a while
  • Even if the cookie is stolen, it will be no longer valid after a while

JSON Web Token (JWT)

• Web standard to encode and exchange client-managed states with tempering protection
• Format: header.payload.signature
  • header: information on the token
  • payload: “main body” of the token
  • signature: encrypted hash value for tempering detection

JWT Header

• JSON data (encoded into Base64 string)
• Typically has two fields
  • alg (hashing algorithm)
  • typ (token type)
• Example

  {
      "alg": "HS256",
      "typ": "JWT"
  }
  

  →  eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Payload

• JSON data (encoded to Base64)
• Contains main information
• Example

  {
      "iss": "http://oak.cs.ucla.edu",
      "jti": "3gxhylhd",
      "exp": 11253352,
      "user": "junghoo"
  }
  

  → eyJrZXkiOiJ2YWwiLCJpYXQiOjE0MjI2MDU0NDV9
  

  • “Registered claims (=fields)”
    • iss (issuer), jti (JWT ID), iat (issued at, # seconds since 1970-01-01T00:00:00Z UTC), exp (expires at), sub (subject), aud (audience), …
  • No claim is required. “Unregistered claims” can be used

Signature

• Secret-key encrypted hash of header.payload (encoded into Base64)
• Example

  HMACSHA256(header.payload,"secret password")   
  → eUiabuiKv-8PYk2AkGY4Fb5KMZeorYBLw261JPQD5lM
  

• When the JWT is tempered, a hacker cannot generate a correct signature without knowing the correct password
• The creator of JWT can check tempering by comparing attached signature with the computed hash value

Final JWT

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9           // header
.eyJrZXkiOiJ2YWwiLCJpYXQiOjE0MjI2MDU0NDV9      // payload
.eUiabuiKv-8PYk2AkGY4Fb5KMZeorYBLw261JPQD5lM   // signature

{
    "alg": "HS256",
    "typ": "JWT"
}.{
    "iss": "http://oak.cs.ucla.edu",
    "jti": "3gxhylhd",
    "exp": 11253352,
    "user": "junghoo"
}.signature

• JWT is sent to the browser
  • Browser sends it back in future requests

User Authentication

• Q: How does server authenticate the identity of a user?
• Q: How can we let a user authenticate once, without asking for authentication for every request?
• Q: After authentication, what should we store in the cookie?
• A: Two choices
  • Username
  • “Session ID”

Session

• When user logs in, the server creates a “session”
  • All session-related “states” reside on the server
  • A unique session ID is associated with a session and set as a cookie
  • Given a session ID in a request, the server obtains session related “states” from local “session data store”
• Q: What are the pros and cons of using session ID vs username?

What We Learned

• Stateless HTTP protocol
• Cookie
• Same-origin policy
• Cookie theft, cookie poisoning, secure cookie
• JSON Web token (JWT)
• User authentication and session management

References

• Cookie: RFC 6265
• JSON Web Token