Weak Session ID
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep and psalm as tools, both specialist SAST tools. The code_pattern targets custom session ID generation using rand(), md5(), or uniqid(), and short session.sid_length in php.ini — these patterns require static analysis to detect and won't be caught by a default linter or compiler.
Closest to 'simple parameterised fix' (e3). The quick_fix is to use PHP's default session handler with session.hash_function=sha256 and session.entropy_length=32, and never generate session IDs manually. This is a configuration change plus replacing custom generation calls — a small targeted fix within one component rather than a single one-liner, but not a multi-file refactor.
Closest to 'localised tax' (b3). The applies_to scope is web context only, and session ID generation is typically handled in one place (session initialization and login flow). Once corrected, the rest of the codebase is largely unaffected. The burden is real but contained to the authentication/session layer.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field explicitly states that developers assume PHP's built-in session_start() always generates cryptographically secure session IDs, when in fact older PHP versions used weak entropy sources. A competent developer familiar with modern PHP would reasonably assume the built-in is safe, making this a serious trap that contradicts reasonable expectations based on documentation and common belief.
Also Known As
TL;DR
Explanation
A weak session ID is one that is too short, uses a predictable algorithm (sequential numbers, MD5 of timestamp), or is derived from guessable input. Attackers can enumerate or predict valid session tokens to hijack authenticated sessions without needing credentials. PHP's default session ID generator is cryptographically secure when session.use_strict_mode is enabled and the session handler uses random_bytes() internally — avoid custom session ID generation unless you use random_bytes(32) or similar.
Common Misconception
Why It Matters
Common Mistakes
- Using a custom session ID generation function instead of PHP's session_regenerate_id().
- Short session IDs (less than 128 bits of entropy) that are feasible to enumerate.
- Not regenerating the session ID after login — allows session fixation attacks.
- Including user-supplied values (like user ID) in the session ID, reducing its unpredictability.
Avoid When
- Never generate session IDs manually using rand(), mt_rand(), uniqid(), or md5(time()).
- Do not transmit session IDs in URLs — always use HttpOnly, Secure cookies.
When To Use
- Use PHP's built-in session_start() with session.use_strict_mode=1 — it generates cryptographically secure session IDs automatically.
- Regenerate the session ID after login with session_regenerate_id(true) to prevent fixation attacks.
Code Examples
// Predictable session IDs
$sessionId = md5($userId . time()); // time-based, guessable// PHP's session_start() with secure config generates cryptographically
// random session IDs by default (uses /dev/urandom)
ini_set('session.entropy_length', 32);
ini_set('session.hash_function', 'sha256');
ini_set('session.hash_bits_per_character', 6);
// Result: 43+ char session ID from CSPRNG
// For API tokens — random bytes
$token = bin2hex(random_bytes(32)); // 64 char hex token
$stored = hash('sha256', $token); // store hash in DB, send raw to client