Skip to main content

​
Overview

This vulnerability occurs when an application fails to properly invalidate user sessions after a period of inactivity (idle timeout) or after a maximum total duration (absolute timeout). If sessions remain valid indefinitely or for excessively long periods (e.g., months or years), the risk of session hijacking increases significantly. An attacker who manages to steal a session identifier (e.g., via XSS, network sniffing if not Secure, or guessing) has a much larger window of opportunity to reuse it. Furthermore, users accessing the application from shared computers might leave their sessions active inadvertently if there’s no timeout. ⏳➡️🔓

​
Business Impact

Insufficient session expiration leads to:
  • Prolonged Session Hijacking Window: Stolen session tokens remain valid for longer, increasing the chance an attacker can successfully use them.
  • Increased Risk from Shared Computers: Users might remain logged in on public terminals, allowing subsequent users to access their accounts.
  • Resource Consumption: Maintaining a large number of inactive sessions can consume server memory.
  • Compliance Issues: Many security standards mandate specific session timeout durations.

Reference Details

CWE ID: CWE-613 OWASP Top 10 (2021): A07:2021 - Identification and Authentication Failures Severity: Medium

​
Framework-Specific Analysis and Remediation

Session expiration is typically managed through framework configuration settings that control cookie expiry and server-side session data lifetime. Key Remediation Principles:
  1. Implement Idle Timeout: Automatically log out users after a period of inactivity (e.g., 15-30 minutes). This involves tracking the last activity time on the server-side session.
  2. Implement Absolute Timeout: Automatically log out users after a fixed maximum duration, regardless of activity (e.g., 8-24 hours). This limits the maximum lifetime of any session identifier.
  3. Secure Logout Functionality: Provide a clear logout button that properly invalidates the session on the server-side.
  4. Cookie Expiry vs. Server Expiry: Ensure both the session cookie’s expiry (Expires/Max-Age attributes) and the server-side session data’s lifetime are configured appropriately. Server-side expiration is generally more critical.
  • Python
  • Java
  • .NET(C#)
  • PHP
  • Node.js
  • Ruby

​
Framework Context

Configuring SESSION_COOKIE_AGE and SESSION_SAVE_EVERY_REQUEST in Django settings.py. Flask requires configuring the session interface (e.g., PERMANENT_SESSION_LIFETIME for Flask-Session).

​
Vulnerable Scenario 1: Django Session Never Expires

# settings.py (Django)
# DANGEROUS: Setting age to None or a very large number means the session
# cookie might persist indefinitely based on browser settings, and server-side
# data might not be cleaned up efficiently depending on session backend.
SESSION_COOKIE_AGE = None # Or a huge value like 315360000 (10 years)

# DANGEROUS: If False (default is False), idle timeout doesn't work effectively.
# The session expiry is only updated when the session is modified.
SESSION_SAVE_EVERY_REQUEST = False

​
Vulnerable Scenario 2: Flask Default Session Lifetime (Browser Session)

Flask’s default client-side cookie session typically lasts only for the browser session unless session.permanent = True is set along with PERMANENT_SESSION_LIFETIME. If using server-side sessions (like Flask-Session), defaults might be too long or missing.
# app.py (Flask - built-in session)
app.secret_key = '...' # Needed for session
# No PERMANENT_SESSION_LIFETIME configured, session might expire only on browser close.

@app.route('/login')
def login():
    # ... login logic ...
    # DANGEROUS: If PERMANENT_SESSION_LIFETIME is very long or default (31 days).
    session.permanent = True # Mark session to use lifetime
    # ...

​
Mitigation and Best Practices

  • Django: Set SESSION_COOKIE_AGE to a reasonable absolute timeout (e.g., 8 * 60 * 60 for 8 hours). Set SESSION_SAVE_EVERY_REQUEST = True to enable idle timeout behavior (session expiry is reset on each request). Configure the session cleanup mechanism (./manage.py clearsessions).
  • Flask: Set PERMANENT_SESSION_LIFETIME (a timedelta object or seconds) to a reasonable absolute timeout. Ensure session.permanent = True is set after login if using this lifetime. For idle timeout, custom logic tracking last activity time in the session is usually needed.

​
Secure Code Example

# settings.py (Django - Secure)
# SECURE: Absolute timeout (e.g., 8 hours)
SESSION_COOKIE_AGE = 8 * 60 * 60

# SECURE: Enable idle timeout (resets expiry on each request)
SESSION_SAVE_EVERY_REQUEST = True

# Ensure SESSION_EXPIRE_AT_BROWSER_CLOSE = False if using AGE for persistence
SESSION_EXPIRE_AT_BROWSER_CLOSE = False

# app.py (Flask - Secure Lifetime)
from datetime import timedelta

app.secret_key = os.environ.get('SECRET_KEY') # Load securely
# SECURE: Set absolute timeout (e.g., 4 hours)
app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(hours=4)

@app.route('/login-secure')
def login_secure():
    # ... login logic ...
    session.permanent = True # SECURE: Apply the configured lifetime
    session['user_id'] = user.id
    # Optional: Store initial login time for absolute timeout independent of activity
    session['login_time'] = datetime.utcnow()
    # Optional: Update last activity time for idle timeout (requires checking on each request)
    session['last_activity'] = datetime.utcnow()
    # ...

# Add a check in a @app.before_request handler for idle/absolute timeout

​
Testing Strategy

Log into the application.
  • Idle Timeout: Leave the browser inactive for longer than the configured idle timeout period. Try performing an action (e.g., refresh page, click link). You should be logged out or prompted to log back in.
  • Absolute Timeout: Note the login time. Wait longer than the configured absolute timeout period (even if you were active). Try performing an action. You should be logged out. Inspect the session cookie’s Expires/Max-Age attribute in browser developer tools (though server-side expiration is more important).