sessions

Overview

Once you have logged in, the application needs a way to remember you across many requests without asking for your password each time. That memory is a session. In authentication CTF challenges, sessions are a frequent target: if you can predict, steal, fixate, or fail to invalidate a session, you can act as another user without ever knowing their credentials. This lesson explains how sessions work and where they break.

Learning objectives

• Explain what a session is and why applications use them.
• Describe how session identifiers are created, transmitted, and validated.
• Recognize the common session weaknesses that authentication challenges exploit.
• State the defensive properties a secure session must have.

Core concept

A session is server-side state representing an authenticated user, tied to a unique session identifier (session ID) that the client presents on each request. After a successful login, the server creates a session (recording who the user is and when they logged in) and issues the session ID to the client — most commonly in a cookie. On every following request, the client returns the session ID, the server looks it up, and it treats the request as coming from that user.

The session ID is therefore a bearer credential: whoever holds it is the user, as far as the server is concerned. That single fact drives every session attack and every session defense. Protecting the session ID — its unpredictability, its confidentiality in transit, and its lifecycle — is what keeps authenticated state trustworthy.

How it works

A well-designed session mechanism has several moving parts:

• Generation — On login, the server generates a session ID using a cryptographically secure random source so it cannot be guessed or predicted from other IDs.
• Transmission — The ID is sent to the client, typically in a Set-Cookie response. Secure deployments mark the cookie HttpOnly (unreadable by JavaScript), Secure (only sent over HTTPS), and with an appropriate SameSite value (limiting cross-site sending).
• Validation — On each request the server confirms the presented ID maps to an active, unexpired session and to the expected user.
• Rotation — On privilege changes such as login, the server issues a new ID and abandons the old one, so a value known before login cannot be reused afterward.
• Termination — On logout or timeout, the server destroys the session so the ID can never be used again.

When any of these steps is weak, a challenge (or an attacker) exploits the gap:

• Predictable session IDs — If IDs are sequential or derived from time or user data, an attacker can compute or guess a valid ID for another user.
• Session hijacking — If the ID is exposed (transmitted over plain HTTP, leaked in a URL, or readable by injected script), whoever captures it can replay it.
• Session fixation — If the server keeps the same ID before and after login, an attacker who plants a known ID in a victim's browser becomes authenticated as the victim once they log in.
• Missing invalidation — If logout or expiry does not truly destroy the session server-side, an old ID keeps working.

Practical example

In an isolated lab application, you log in as a low-privilege user and inspect your session cookie. Suppose its value is session=1004. You notice the number looks like a simple counter. Changing it to session=1003 and reloading shows you a different user's dashboard — the IDs are predictable, so the server is trusting an easily forged bearer credential. The flag lives in the admin account's page, and because IDs are sequential, you can locate the admin's ID and present it.

A second lab demonstrates fixation: the app assigns a session ID before login and never changes it afterward. If you can get a victim (in the lab, a simulated user) to authenticate while carrying an ID you already know, you can then use that same ID to ride their now-authenticated session. Both scenarios reduce to the same root cause: the session ID was not unpredictable, confidential, and rotated on login. These are controlled teaching exercises against systems you are authorized to test.

Cybersecurity relevance

Session management appears explicitly in the OWASP guidance on authentication and session handling because broken sessions are a direct path to account takeover — often without any password ever being cracked. In real systems, the defenses are the mirror image of the attacks: generate IDs from a secure random source, transmit them only over HTTPS with HttpOnly/Secure/SameSite cookies, rotate the ID on login to defeat fixation, enforce absolute and idle timeouts, and invalidate sessions server-side on logout. Understanding sessions from the attacker's side in a lab makes these controls concrete rather than abstract checklist items.

Common mistakes

• Generating guessable IDs using counters, timestamps, or user data instead of secure randomness.
• Not rotating the session ID on login, leaving the door open to fixation.
• Only "logging out" on the client (deleting the cookie) while the server-side session remains valid.
• Exposing the session ID in URLs, logs, or over unencrypted connections where it can be captured.

Key takeaways

• A session is server-side state for an authenticated user, referenced by a session ID the client presents on each request.
• The session ID is a bearer credential: its unpredictability, confidentiality, and lifecycle are what keep authentication trustworthy.
• Common session attacks — prediction, hijacking, fixation, and missing invalidation — all stem from weaknesses in generating, protecting, rotating, or destroying the ID.
• Secure sessions use random IDs, protective cookie flags, rotation on login, timeouts, and true server-side termination.

Check your understanding

• Why is a session ID considered a "bearer credential," and what does that imply about protecting it?
• How does rotating the session ID on login defend against session fixation?
• Why is deleting a cookie in the browser not a sufficient logout on its own?