TryBugHunt

The 50,000-Year Token

Easyjavascript

Session Expiry Validator with Millisecond vs. Second Scale Mismatch

0:00
Step 1: Test Traffic & Expose Flaw
/**
 * Session Token Validator Service
 * Checks session validity and expiration against gateway timestamps.
 */

class SessionValidator {
  constructor() {
    this.sessions = new Map();
  }

  createSession(userId, ttlSeconds, nowMs = 1700000000000) {
    // AI Attempt: Computes expiration in milliseconds
    const expiresAt = nowMs + (ttlSeconds * 1000);
    const session = {
      userId,
      expiresAt,
      createdAt: nowMs
    };
    this.sessions.set(userId, session);
    return session;
  }

  isSessionValid(userId, currentTimestampSeconds) {
    const session = this.sessions.get(userId);
    if (!session) {
      return false;
    }

    // AI Attempt: Compares session expiresAt with current gateway timestamp
    // Gateway supplies current time in standard Unix seconds (e.g. 1700003600)
    if (session.expiresAt <= currentTimestampSeconds) {
      return false; // Expired
    }

    return true;
  }
}

module.exports = { SessionValidator };
Step 1: Test Traffic & Expose FlawClient-side WASM

Run a scenario below to trace session validation. Prove that expired sessions remain accepted as valid due to millisecond vs. second scale mismatch.

Choose Traffic Scenario to TestClick to simulate
Architectural Guide & Interview Notes

Deep Dive: The 50,000-Year Token

An engineering analysis of why this AI-generated Pull Request passed isolated unit tests, how multi-tenant traffic exposes the architectural flaw, and how interviewers score your response.

The Root Cause Anti-Pattern

In web services, timestamp unit confusion is a frequent source of security defects. Timestamps generated in milliseconds (Date.now() + ttl * 1000) are 1,000× larger than Unix epoch timestamps in seconds. Comparing expiresAt <= currentTimestampSeconds will never trigger expiration for ~52,000 years.

The Interviewer's Scoring Rubric

Candidates are assessed on whether they jump to trial-and-error editing or follow a hypothesis-driven approach. A "Strong Hire" candidate restates the data flow between modules, explains why single-client unit tests passed, crafts an adversarial probe showing cross-tenant leakage, and implements a surgical 1-line patch without breaking existing contracts.

Candidate Strategy for the Code Comprehension Round

  1. 1Map Module ContractsTrace how the gateway invokes the underlying service. Note what data is passed by reference vs. by value.
  2. 2Break It With An Adversarial ProbeSimulate concurrent or sequential traffic across multiple identities to force shared state mutation.
  3. 3Deliver a Surgical PatchMake the minimal required diff to ensure proper per-client state isolation without refactoring unnecessary files.
← Back to Code Comprehension Directory
Next scenario:The Leaky Token Bucket (python)