Session Fixation on Docker

Session fixation vulnerabilities in Docker environments often stem from improper session management across containerized applications. When containers share the same network or when session tokens are predictable, attackers can hijack user sessions by forcing a known session ID onto victims.

In Docker deployments, session fixation commonly occurs through:

• Shared network vulnerabilities: Containers on the same Docker network can intercept session cookies if not properly isolated
• Stateless session storage: Using Redis or similar stores without proper session rotation
• Predictable session IDs: Using weak session generation algorithms in containerized apps
• Improper cookie flags: Missing Secure, HttpOnly, or SameSite attributes in containerized web apps

Here's a vulnerable Node.js/Express application running in Docker that demonstrates session fixation:

// app.js - Vulnerable session fixation example
const express = require('express');
const session = require('express-session');
const app = express();

// INSECURE: Predictable session ID generation
app.use(session({
  secret: 'supersecretkey',
  resave: false,
  saveUninitialized: true,
  cookie: { secure: false, httpOnly: false, sameSite: 'none' } // Missing security flags
}));

app.get('/set-session', (req, res) => {
  // Attacker-controlled session fixation
  req.session.user = { id: 1, role: 'user' };
  res.send(`Session ID: ${req.sessionID}`);
});

app.get('/admin', (req, res) => {
  if (req.session.user && req.session.user.role === 'admin') {
    res.send('Welcome Admin!');
  } else {
    res.send('Access Denied');
  }
});

app.listen(3000, () => console.log('App running on port 3000'));

Deploying this in Docker creates multiple attack vectors:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]

Attack scenario in Docker:

1. Attacker accesses /set-session to obtain a known session ID
2. Attacker forces victim to use this session ID (via URL parameter or XSS)
3. Victim authenticates using the fixed session ID
4. Attacker accesses victim's session through Docker network

The Docker networking model amplifies this risk when containers share the same bridge network without proper isolation. An attacker container can potentially intercept traffic or access shared volumes containing session data.

Detecting session fixation in Docker requires both runtime monitoring and static analysis. middleBrick's Docker-aware scanning identifies session fixation through several Docker-specific checks:

Using middleBrick CLI to scan a Docker-deployed API:

# Scan a Docker-deployed API endpoint
middlebrick scan https://api.example.com --output json

# Scan with Docker-specific context
middlebrick scan http://localhost:3000 --docker-context --verbose

Manual Docker detection steps:

1. Check container network configuration:

   docker network ls
   docker inspect <container_id>

2. Examine session storage:

   docker exec <container_id> ls /app/data
   # Look for session files or Redis connections

3. Analyze application code:

   docker exec <container_id> cat app.js
   # Look for session fixation patterns

4. Test session fixation:

   # Get session ID
   curl -c cookies.txt http://localhost:3000/set-session
   
   # Use fixed session ID
   curl -b cookies.txt http://localhost:3000/admin

middleBrick's black-box scanning specifically tests for session fixation by:

• Attempting to set known session IDs
• Checking for predictable session token patterns
• Verifying proper session rotation after authentication
• Testing for missing security cookie attributes

The scanner reports findings with severity levels and Docker-specific remediation guidance, mapping to OWASP API Security Top 10 (A2: Broken Authentication) and compliance frameworks.

Remediating session fixation in Docker requires both application-level fixes and Docker configuration changes. Here are Docker-specific solutions:

1. Secure Session Management in Containerized Apps

// Secure session configuration
const session = require('express-session');

app.use(session({
  secret: process.env.SESSION_SECRET, // Use environment variables
  resave: false,
  saveUninitialized: false,
  genid: (req) => {
    // Strong session ID generation
    return require('crypto').randomBytes(32).toString('hex');
  },
  rolling: true, // Renew session ID periodically
  cookie: {
    secure: true, // Only over HTTPS
    httpOnly: true, // Prevent JavaScript access
    sameSite: 'strict', // CSRF protection
    maxAge: 3600000 // 1 hour timeout
  }
}));

// Regenerate session after login
app.post('/login', (req, res) => {
  // Authenticate user...
  req.session.regenerate((err) => {
    if (err) return res.status(500).send('Session error');
    req.session.user = { id: user.id, role: user.role };
    res.send('Login successful');
  });
});

2. Docker Security Configuration

FROM node:18-alpine

# Use non-root user
RUN addgroup -g 1001 -S nodejs
RUN adduser -S nodejs -u 1001

WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .

# Use environment variables for secrets
ENV SESSION_SECRET=your-super-secret-key-here
ENV REDIS_URL=redis://redis:6379

# Expose only necessary ports
EXPOSE 3000

# Drop privileges
USER nodejs

CMD ["node", "app.js"]

3. Docker Compose with Security Isolation

version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - SESSION_SECRET=${SESSION_SECRET}
      - NODE_ENV=production
    networks:
      - app-network
    volumes:
      - ./:/app:ro # Read-only access

  redis:
    image: redis:7-alpine
    command: redis-server --requirepass ${REDIS_PASSWORD}
    networks:
      - app-network
    volumes:
      - redis_data:/data

networks:
  app-network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16

volumes:
  redis_data:

4. Runtime Security Monitoring

# Monitor for session fixation attempts
docker run --name session-monitor \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e MONITOR_TARGET=app \
  -e ALERT_THRESHOLD=5 \
  session-fixation-monitor

Key remediation principles:

1. Always regenerate session IDs after privilege level changes
2. Use strong, random session tokens with sufficient entropy
3. Enable all cookie security flags (Secure, HttpOnly, SameSite)
4. Isolate containers using Docker networks and non-root users
5. Store sessions securely using Redis with authentication
6. Implement session timeouts and inactivity expiration

middleBrick's Pro plan includes continuous monitoring that automatically scans your Docker-deployed APIs on a configurable schedule, alerting you when session fixation vulnerabilities are detected. The GitHub Action integration allows you to fail builds if session security scores drop below your threshold, preventing vulnerable containers from reaching production.