👨‍💻
Application Security Handbook
  • Application Security Handbook
  • Web Application
    • Authentication
      • Authentication with Login and Password
      • Authentication with Phone Number
      • OAuth 2.0 Authentication
      • Multi-factor Authentication
      • Default Passwords
      • Password Change
      • Password Policy
      • Password Reset
      • Password Storage
      • One Time Password (OTP)
      • Email Address Confirmation
    • Authorization
    • Concept of Trusted Devices
    • Content Security Policy (CSP)
    • Cookie Security
    • Cryptography
      • Cryptographic Keys Management
      • Encryption
      • Hash-based Message Authentication Code (HMAC)
      • Hashing
      • Random Generators
      • Universal Unique Identifier (UUID)
    • Error and Exception Handling
    • File Upload
    • Input Validation
    • JSON Web Token (JWT)
    • Logging and Monitoring
    • Output Encoding
    • Regular Expressions
    • Sensitive Data Management
    • Session Management
    • Transport Layer Protection
    • Vulnerability Mitigation
      • Brute-force
      • Command Injection
      • Cross-Site Request Forgery (CSRF)
      • Cross-Site Scripting (XSS)
      • Mass Parameter Assignment
      • Parameter Pollution
      • Path Traversal
      • Regular Expression Denial of Service (ReDoS)
      • SQL Injection (SQLi)
      • XML External Entity (XXE) Injection
Powered by GitBook
On this page
  • Overview
  • General
  • Stateful approach related
  • Stateless approach related
  • References
  1. Web Application

Session Management

PreviousSensitive Data ManagementNextTransport Layer Protection

Last updated 1 year ago

Overview

This page contains recommendations for the implementation of session management.

There are two approaches to session management: Stateful and Stateless.

  • In the case of the Stateful approach, a session token is generated on the server side, saved to a database and passed to a client. The client uses this token to make requests to the server side. Therefore, the server-side stores the following bundle: account_id:session_id.

  • In the case of the Stateless approach, a session token is generated on the server side (or by a third-party service), signed using a private key (or secret key) and passed to a client. The client uses this token to make requests to the server side. Therefore, the server side needs to store a public key (or secret key) to validate the signature.

General

  • Do not store any sensitive data (tokens, credentials, PII, etc.) in a session ID.

  • Use the session management built into the framework you are using instead of implementing a homemade one from scratch.

  • Use up-to-date and well-known frameworks and libraries that implement session management.

  • Review and change the default configuration of the framework or library you are using to enhance its security.

  • Consider session IDs as untrusted data, as any other user input.

  • Implement an idle or inactivity timeout for every session.

Clarification

An idle or inactivity timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by an application for a given session ID.

  • Implement a mechanism to allow users to actively close a session (logout) after they have finished using an application.

  • Invalidate the session at least on the server side while closing a session.

  • Use different session IDs and token names for pre- and post-authentication flows.

Clarification

Using different tokens allows an application to keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

Clarification

If caching application contents is allowed, session IDs can be cached as a part of the Set-Cookie header.

  • Do not pass a session ID in an URL (path, query or fragment).

  • Renew or regenerate a session ID after any privilege level change within the associated user session (anonymous -> regular user, regular user -> admin user, etc.).

Clarification

The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Common scenarios to include:

  • Password changes.

  • Permission changes.

  • Switching from a regular user role to an administrator role within an application.

The session ID regeneration is mandatory to prevent session fixation attacks, where an attacker sets the session ID on the victim user's web browser instead of gathering the victim's session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS.

  • If a framework is used, change the default session ID name to something neutral, for example, sessionid or id.

  • Implement an absolute timeout for every session regardless of session activity.

Clarification

An absolute timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by an application.

  • Provide users with the ability to manage active sessions (view and close active sessions).

Stateful approach related

  • Use session IDs of length 16+ bytes.

  • Do not accept a session ID that has never been generated by an application. In case of receiving one, generate a new one for anonymous access and set it to a user.

Stateless approach related

  • Use the exp claim to implement a session timeout.

  • Use the following algorithm to implement the logout functionality:

    • Store the jti claim (unique token identifier) for each issued token.

    • If a user logged out from an application, move the jti to a list of blocked tokens.

    • Remove a token from the block list when a token expires (check the exp claim to determine if a token has expired).

References

Use the base cookie format to store session IDs, see the page.

Do not cache session IDs if caching application contents is allowed, see the page.

Handle and store session IDs according to the page.

Log successful and unsuccessful events related to a session lifecycle (such as creation, regeneration, revoke) including attempts to access resources with invalid session IDs, see the page.

Use the ultimate cookie format to store session IDs, see the page.

Generate a session ID using a cryptographically strong generator, see the page.

Use JSON Web Tokens (JWT) to implement stateless session management, see the page.

Cookie Security
Transport Layer Protection
Session Management
Logging and Monitoring
Cookie Security
Cryptography: Random Generators
JSON Web Token (JWT)
OWASP Cheat Sheet Series: Session Management Cheat Sheet