Session Security, Cookies, Tokens and Hijacking Prevention — DedSec Project

A session links a sequence of requests to an authenticated or otherwise stateful context. Session security fails when identifiers are exposed, predictable, accepted in the wrong context, insufficiently protected, or not revoked when the underlying authorization changes.

Authorized-use boundary: Test session controls only with accounts and applications you own or are explicitly authorized to assess. Use synthetic accounts and disposable tokens. Do not intercept or reuse another person's session.

Learning objectives

• understand server-side sessions and bearer tokens;
• evaluate cookie attributes and browser boundaries;
• distinguish token theft, fixation, replay, and authorization flaws;
• understand session rotation and revocation;
• reason about CSRF, XSS, and token storage relationships;
• design safe session tests.

Session identifiers

A session identifier should be unpredictable, sufficiently long, and meaningless to the client. The server maps it to state such as user identity, authentication strength, permissions, creation time, and expiry.

If a session identifier is a bearer credential, possession may be enough to act as that session. Protect it like a secret.

Cookie protections

Important attributes include:

• Secure: send the cookie only over HTTPS;
• HttpOnly: prevents ordinary JavaScript access, reducing some token-theft paths;
• SameSite: constrains cross-site sending and helps reduce CSRF risk;
• Path/Domain: limit where the cookie is sent;
• appropriate lifetime and deletion behavior.

Cookie attributes do not replace server-side authorization.

Session fixation

Session fixation occurs when an application keeps an identifier across a security-sensitive transition such as login. A strong pattern is to rotate the session identifier after authentication, privilege elevation, password reset, or other major trust changes.

Replay and revocation

Long-lived bearer tokens increase the window in which theft matters. Systems should define expiry, refresh behavior, revocation, logout semantics, password-reset behavior, device/session management, and what happens when an account is disabled.

Tokens and context

A signed token can still be unsafe if it is accepted by the wrong service, tenant, audience, or workflow. Validate issuer, audience, expiry, intended algorithm/key, and authorization state. Do not assume “signature valid” means “request authorized.”

OAuth/OIDC depth is covered in Modules 39 and 92.

XSS and session theft

If an application has cross-site scripting, an attacker may be able to act within the victim's browser context even when HttpOnly protects direct cookie reading. XSS prevention therefore remains important to session security.

CSRF

Cross-site request forgery abuses the browser's ability to send credentials automatically. Defenses can include SameSite cookies, anti-CSRF tokens, origin checks where appropriate, and avoiding state-changing GET requests.

Safe session tests

With two test accounts in a local application, verify:

• session identifier changes after login;
• logout invalidates the session server-side;
• password change or account disable has the expected session effect;
• one user's identifier cannot authorize another user's object;
• expired tokens are rejected;
• cookies use appropriate attributes.

Use only your own test sessions.

Logging

Session logs should support investigation without recording raw bearer tokens. Useful context includes user/subject identifier, session or token fingerprint, client/device context where appropriate, authentication event, privilege changes, logout/revocation, and authorization failures.

Common mistakes

• Logging full session cookies or bearer tokens.
• Treating logout as a client-side UI action only.
• Keeping the same session identifier before and after login.
• Validating token signature but not audience or authorization.
• Storing long-lived tokens in insecure locations.
• Testing by stealing another person's session.

Safe lab

Use a deliberately vulnerable local web application or a small test app with two synthetic users. Observe cookie attributes, log in and log out, verify identifier rotation, and test whether a revoked session remains accepted. Record only sanitized token fingerprints.

Knowledge check

1. Why are bearer tokens sensitive?
2. What problem does session rotation address?
3. Why is a valid JWT signature insufficient for authorization?
4. How does SameSite relate to CSRF?
5. What session evidence can be logged without storing secrets?

Guided study workflow

Use the shared Study Method. Focus on lifecycle and authorization, not token collection.

Continue with

Recommended next modules: 14, 39, 52, 70, 92.