🔑 Session Management

When you log into a website, the server creates a session — a temporary record that says "this user is authenticated and this is who they are." The server gives your browser a session token (usually stored in a cookie), and every subsequent request you make includes that token so the server knows it is still you.

Without sessions, the web would be stateless — you would have to type your username and password on every single page you visit. Sessions solve this by remembering you are logged in as you navigate around the site.

Think of a session like a wristband at a music festival. When you arrive, you show your ticket (login credentials) at the gate. They give you a wristband (session token). For the rest of the day, you just show the wristband to access different stages and areas. You do not need to show your ticket every time. But if someone steals your wristband, they can get in as you.

How Sessions Work Step by Step

Step 1: The user submits their username and password via the login form.

Step 2: The server verifies the credentials (checking the bcrypt hash against the stored hash).

Step 3: If valid, the server creates a session object containing the user's ID, role, and login time. It generates a random, unpredictable session ID (e.g., a 128-bit random string) and stores the session server-side.

Step 4: The server sends the session ID to the browser as a cookie with security flags: HttpOnly (JavaScript cannot read it), Secure (only sent over HTTPS), and SameSite (prevents cross-site request forgery).

Step 5: On every subsequent request, the browser automatically sends the cookie. The server looks up the session ID and knows who the user is.

Step 6: When the user logs out (or the session times out after inactivity), the server destroys the session and the cookie becomes invalid.

Session Security Threats

Session hijacking occurs when an attacker steals a user's session token. If the token is transmitted over HTTP (not HTTPS), anyone on the same network can intercept it. This is why the Secure flag is essential — it ensures the cookie is only sent over encrypted connections.

Session fixation is when an attacker sets a known session ID before the user logs in, then uses that same ID after the user authenticates. The defence: regenerate the session ID immediately after successful login, making the old ID useless.

Cross-Site Request Forgery (CSRF) tricks a logged-in user's browser into making requests to a site where they are authenticated. The SameSite cookie flag prevents this by ensuring cookies are only sent for requests originating from the same site.

⚠️ Real-World: The Firesheep Attack (2010)

Firesheep was a Firefox extension that made session hijacking trivially easy. On any public Wi-Fi network, it would automatically detect and display other users' session cookies for sites like Facebook and Twitter (which did not yet use HTTPS by default). Anyone could click on a detected session and instantly access that person's account. Over 1 million people downloaded Firesheep. This single tool forced Facebook, Twitter, and other major sites to switch to HTTPS by default — protecting session cookies with the Secure flag. It demonstrated why session management is critical for security.