Side-Channel Attack
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep and burpsuite — both specialist/SAST tools. Semgrep can flag == or === comparisons on security-sensitive values and missing hash_equals() calls, but the more subtle timing or cache-channel issues (HTTP status code leaks, error-message divergence) require manual review or runtime testing, putting this squarely at d5 rather than d3.
Closest to 'simple parameterised fix' (e3). The quick_fix is concise: swap == / === / strcmp() for hash_equals() in PHP for HMAC/token comparisons. The common_mistakes are largely pattern-replacements within one component (auth layer). Normalising HTTP status codes and error messages is similarly localised. Not quite a one-liner across the board, but well within one component — e3.
Closest to 'localised tax' (b3). The applies_to contexts are web and api, and the mitigation is largely confined to the authentication/comparison layer. It doesn't reshape the whole codebase, but every developer touching auth or token-comparison code must remember the constant-time rule. The ongoing tax is real but contained.
Closest to 'serious trap' (t7). The misconception field explicitly states the canonical wrong belief: 'Side-channel attacks only apply to hardware and embedded systems.' A competent web developer who knows the term from cryptography/hardware contexts will naturally assume it doesn't apply to their PHP API — then write === on a MAC comparison without a second thought. This contradicts reasonable intuition about where the concept applies, warranting t7.
Also Known As
TL;DR
Explanation
Side-channel attacks exploit indirect information leaks. Timing attacks are the most relevant to PHP applications: functions like strcmp() return early on the first differing byte, leaking information about how many characters match. An attacker who can measure response times can recover secrets one character at a time. Always use hash_equals() for comparing security-sensitive strings such as HMAC signatures, CSRF tokens, and password hashes, as it takes constant time regardless of input.
Common Misconception
Why It Matters
Common Mistakes
- Comparing secrets with === or strcmp() — early exit on first mismatch leaks information via timing.
- Not using hash_equals() for HMAC or token comparison in PHP.
- Error messages that differ based on which validation step failed — reveals structure of valid input.
- Returning HTTP 401 vs 403 vs 404 for auth failures that reveal whether a resource or user exists.
Code Examples
// Timing side channel — exits early on first mismatch
if (\$_POST['token'] === \$secret) { grantAccess(); }// Constant-time comparison — same duration regardless of input
if (hash_equals(\$secret, \$_POST['token'] ?? '')) { grantAccess(); }
// For passwords:
password_verify(\$input, \$storedHash); // constant-time built-in
// Prevent user enumeration via timing:
// Always run password_verify even for unknown users
\$hash = \$user?->password ?? '\$argon2id\$v=19\$m=65536,t=4,p=1\$dummy\$dummy';
\$valid = password_verify(\$input, \$hash);
if (!\$user || !\$valid) abort(401);