3. Master the Basics, Break the Web: Cookies & Sessions

Cookies

1. What Cookies Are ?

Cookies are small pieces of data stored in the user’s browser and automatically sent with every request to a website. They are used to remember user-specific information such as login sessions, preferences, tracking IDs, and authentication tokens. Because browsers attach cookies to each request, they become a key part of how websites identify and maintain user state.

Pentest Relevance:

• Weak cookie settings can expose sessions to theft or hijacking.
• Missing flags (HttpOnly, Secure, SameSite) increase the risk of XSS or MITM attacks.
• Manipulating cookie values helps test authentication, authorization, and session handling flaws.

💡Example: Cookie: sessionID=abc123 — Changing or stealing this value may give access to another user’s account if sessions aren’t properly protected.

2. Cookie attributes (HttpOnly, Secure, SameSite)

Cookie attributes define how a cookie behaves in the browser and play a major role in protecting sessions. They help control where cookies are sent, who can access them, and how they are used in cross-site requests. Understanding these attributes is essential for evaluating an application’s session security.

HttpOnly

Prevents JavaScript from accessing the cookie. Protects against theft through XSS attacks since scripts cannot read the cookie value.

Pentest Relevance:

• Missing HttpOnly may allow attackers to steal session tokens via XSS.
• Critical for securing login and session cookies.

💡Example: Set-Cookie: session=abc123; HttpOnly

Secure

Ensures the cookie is only sent over HTTPS. Prevents the cookie from being transmitted in plaintext over HTTP.

Pentest Relevance:

• Missing Secure flag allows session leakage on insecure networks.
• Essential for preventing MITM attacks.

💡Example: Set-Cookie: session=abc123; Secure

SameSite

Controls when cookies are sent with cross-site requests to prevent CSRF attacks.
Modes: Strict, Lax, None.

• Strict — cookie sent only from the same site (strongest).
• Lax — allowed on top-level navigations (safe default).
• None — sent on cross-site requests only if Secure is also enabled.

Pentest Relevance:

• Weak SameSite settings can make CSRF exploits possible.
• SameSite=None without Secure = vulnerable configuration.

💡Example: Set-Cookie: session=abc123; SameSite=Lax

3. Session management

Session management is the process of creating, maintaining, and validating a user’s authenticated state after login. Instead of asking users to authenticate on every request, the server issues a session ID that the browser sends with each request. This session represents the user’s identity and permissions until it expires or is terminated.

Pentest Relevance:

• Weak session handling can lead to session hijacking, fixation, or privilege escalation.
• Poor regeneration or long expiration times increase the risk of unauthorized access.
• Testing involves manipulating session tokens, reusing old tokens, and checking invalidation behavior.

💡Example: After login, the server sets: Set-Cookie: sessionID=abc123; HttpOnly; Secure
Changing or reusing this token helps identify session fixation or broken authentication flaws.

4. Session Tokens: How They Are Created & Stored

Session tokens are unique identifiers generated by the server to represent a logged-in user. They are usually random, unpredictable strings designed to prevent guessing or brute-forcing. Once issued, the token is stored in the user’s browser (typically as a cookie) and sent with every request to maintain the session.

Pentest Relevance:

• Weak or predictable tokens make sessions easy to hijack.
• Storing tokens insecurely (e.g., in localStorage) exposes them to XSS attacks.
• Pentesters test randomness, predictability, storage location, and token reuse behavior.

💡Example: A token like sessionID=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... is stored in a cookie. If stored in JavaScript-accessible storage, an attacker with XSS could steal it and impersonate the user.

5. Stateful vs Stateless sessions

Stateful Sessions

Stateful sessions store the user’s session data on the server. The browser only holds a session ID, and the backend maps that ID to stored session details (user ID, roles, preferences, etc.). This requires server-side memory or databases to track active sessions.

Pentest Relevance:

• Session fixation, hijacking, and weak invalidation are common issues.
• Logout must properly destroy server-side session data.
• If session IDs are predictable, attackers can guess valid sessions.

💡Example: sessionID=abc123 → server stores:{ abc123: { user: "admin", role: "admin" } }

Stateless Sessions

Stateless sessions store all session data inside the token itself (e.g., JWT). The server does not keep session data; it only verifies the token’s signature. This makes scaling easier but shifts security responsibility to token integrity.

Pentest Relevance:

• Token tampering becomes critical — weak signing keys or none Algorithm issues are common.
• Token misuse (reuse after logout, long expiration) can lead to persistent unauthorized access.
• Revocation is difficult since tokens are self-contained.

💡Example: A JWT token contains encoded user data: Authorization: Bearer <header.payload.signature> Server validates signature → no need to store session in memory.

6. Local/session storage basics

Local Storage and Session Storage are browser-side storage mechanisms provided by the Web Storage API. They allow websites to store key–value data directly in the user’s browser without sending it automatically to the server. Both are fully client-controlled and should never store sensitive information like session tokens.

Local Storage

Local Storage persists data permanently until manually cleared by the user or application. It survives browser restarts and page reloads, making it ideal for storing UI preferences or cached data.

Pentest Relevance:

• Fully accessible to JavaScript → vulnerable to XSS token theft.
• Often misused to store JWTs, API keys, or auth tokens.
• Long-lived data increases the impact of exploitation.

💡Example: localStorage.setItem(“theme”, “dark”)

Session Storage

Session Storage stores data only for the active browser tab. It is cleared automatically when the tab is closed, but persists during page reloads.

Pentest Relevance:

• Also accessible to JavaScript → vulnerable to XSS-based data theft.
• Safer than Local Storage, but still unsuitable for sensitive session tokens.
• Useful for testing what data applications store during workflows.

💡Example: sessionStorage.setItem("cartItems", "5")

Wrapping up here — next up: Browser Fundamentals

Catch you soon 🙌,
Abinesh