中文
devexamples
← Workflows

阅读中文版本

Session Management Audit Workflow

Review session lifetimes, cookie attributes, rotation, and revocation, and confirm that idle and absolute timeouts match the risk of the data accessed.

intermediate~90 minsecuritysessionaudit

Objective

Verify that session handling is consistent with the sensitivity of the application and cannot be trivially hijacked.

Environment

  • A session implementation to inspect
  • Logs of session creation and expiry

Steps

1. Review cookie attributes for HttpOnly, Secure,

Review cookie attributes for HttpOnly, Secure, and SameSite.

Expected state: Cookies cannot be read by script or sent cross-site.

2. Check idle and absolute timeouts against

Check idle and absolute timeouts against data sensitivity.

Expected state: Sessions do not live longer than justified.

3. Verify rotation at login and privilege

Verify rotation at login and privilege change and revocation capability.

Expected state: Hijacked sessions can be ended and fixed sessions rotated.

4. Test the boundary cases: expired session,

Test the boundary cases: expired session, concurrent sessions, logout all.

Expected state: Behavior is correct and observable.

Decision points

Sticky sessions or stateless tokens?

  • Short tokens with revocation
  • Long sticky sessions

Short-lived tokens with a revocation store balance scale and control; long-lived sessions widen the theft window.

Idle timeout only or absolute too?

  • Both
  • Idle only

Both; an absolute cap bounds the damage of a session that is kept warm by an attacker.

Expected outcome

Sessions have correct cookie attributes, risk-appropriate timeouts, rotation, and revocation, with boundary behavior verified.

Verification

Confirm that an expired or revoked session is rejected immediately and that a replayed old session id after login does not work.

Cleanup

Record findings and update the session configuration documentation.

Overview

Verify that session handling is consistent with the sensitivity of the application and cannot be trivially hijacked. Confirm that an expired or revoked session is rejected immediately and that a replayed old session id after login does not work.

Steps

  1. Review cookie attributes for HttpOnly, Secure, and SameSite. Expected state: Cookies cannot be read by script or sent cross-site.
  2. Check idle and absolute timeouts against data sensitivity. Expected state: Sessions do not live longer than justified.
  3. Verify rotation at login and privilege change and revocation capability. Expected state: Hijacked sessions can be ended and fixed sessions rotated.
  4. Test the boundary cases: expired session, concurrent sessions, logout all. Expected state: Behavior is correct and observable.
curl -si https://app.example.com/login | grep -i set-cookie
# Set-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax; Path=/

Verification

  • Sessions have correct cookie attributes, risk-appropriate timeouts, rotation, and revocation, with boundary behavior verified.

Decision points

  • Sticky sessions or stateless tokens? Options: Short tokens with revocation; Long sticky sessions. Recommended: Short-lived tokens with a revocation store balance scale and control; long-lived sessions widen the theft window.
  • Idle timeout only or absolute too? Options: Both; Idle only. Recommended: Both; an absolute cap bounds the damage of a session that is kept warm by an attacker.