Session Fixation in Django with Dynamodb

Session fixation occurs when an attacker sets or knows a user’s session identifier and tricks the user into authenticating with that identifier. In a Django application using Amazon DynamoDB as the session store, the risk pattern is similar to traditional relational stores, but implementation details in how Django hands out session keys and how DynamoDB models and persists session data can create or expose the vulnerability.

Django’s session framework supports custom backends. When you configure a DynamoDB-backed session store (for example via a third-party DynamoDB session backend), the session key is typically stored as the primary key in a DynamoDB table. If the application does not rotate the session key upon authentication, an attacker who knows or sets the key can reuse it after the user logs in. In DynamoDB, session records are uniquely identified by attributes such as session_key (partition key) and optionally expire_date. Because reads and writes are eventually consistent and latency is low, an attacker can poll or observe the moment a legitimate write confirms the authenticated session, then reuse the fixed key.

Another DynamoDB-specific exposure involves how session data is serialized and stored. If the session payload stored in DynamoDB includes elevated metadata (e.g., user roles or tokens) and the application trusts the session key without additional verification, a fixed key can grant broad access. DynamoDB’s lack of built-in row-level ownership means developers must enforce ownership checks in application logic; missing or weak checks amplify fixation risks. Moreover, if the DynamoDB table uses a global secondary index (GSI) for lookup by user ID without proper key design, it may inadvertently expose mappings between users and session keys, aiding an attacker’s enumeration.

Consider a DynamoDB table SessionStore with session_key as partition key and data as a JSON blob. A vulnerable Django configuration might create a session with a predictable or attacker-supplied key and later authenticate without regenerating the key. For example, an endpoint that accepts a session_id query parameter and sets request.session.session_key directly enables fixation. When the user authenticates, the backend writes an updated item into DynamoDB under the same key, but the key remains controlled by the attacker.

Real-world attack patterns mirror classic OWASP API Top 10 session weaknesses, but DynamoDB’s schema flexibility and key design require precise controls. Without rotating the session key on login and validating that the session was established by the authenticated user, the combination of Django’s session handling and DynamoDB’s storage model creates a concrete fixation surface. Compounded by insufficient input validation on session identifiers and missing checks on session ownership, attackers can maintain access across authentication events.

Remediation centers on ensuring session keys are rotated on authentication, validating session ownership, and designing DynamoDB item structures to support secure lookups without exposing mappings. Below are concrete steps and code examples for a DynamoDB-backed session store in Django.

First, rotate the session key immediately after successful authentication. In Django, override the authenticate flow or use a signal to create a new session key and migrate session data. With DynamoDB, this means writing a new item with a fresh key and removing the old key to prevent reuse.

import boto3
import secrets
from django.conf import settings

dynamodb = boto3.resource('dynamodb', region_name=settings.AWS_REGION)
table = dynamodb.Table('SessionStore')

def rotate_session_key(old_key, user_id):
    # Fetch existing session data
    resp = table.get_item(Key={'session_key': old_key})
    item = resp.get('Item')
    if not item:
        return None
    data = item.get('data', '{}')
    expiry = item.get('expire_date')
    # Create new key and write new item
    new_key = secrets.token_urlsafe(32)
    table.put_item(Item={
        'session_key': new_key,
        'data': data,
        'expire_date': expiry,
        'user_id': user_id
    })
    # Delete old key to prevent reuse
    table.delete_item(Key={'session_key': old_key})
    return new_key

Second, enforce ownership checks on every session validation. When loading a session from DynamoDB, verify that the user_id in the session matches the authenticated user, and ensure the session is not shared across users. This prevents an attacker’s fixed key from being valid after the legitimate user authenticates.

def validate_session(session_key, current_user_id):
    resp = table.get_item(Key={'session_key': session_key})
    item = resp.get('Item')
    if not item:
        return False
    if item.get('user_id') != current_user_id:
        return False
    # Additional checks: expiry, revocation flags can be added here
    return True

Third, design the primary key schema to avoid unintentional exposure. Use a high-entropy session key as the partition key and keep user identifiers in attributes rather than in key names. Do not create a GSI that maps user IDs directly to session keys without access control considerations; if needed, protect the GSI with strict IAM policies and avoid returning it in API responses that could be enumerated.

Finally, apply strong input validation on any session identifier coming from clients. Treat session keys as opaque strings and reject malformed or overly predictable values. Combine these DynamoDB-specific practices with Django’s built-in session rotation hooks and secure cookie flags to reduce the attack surface. Regularly review item TTL configurations and encryption at rest settings to align with data protection requirements.