Log Injection
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list Semgrep as the primary tool, with a specific code pattern targeting raw user input in logging calls. This is not caught by a compiler or default linter, but Semgrep (a SAST tool) can detect the pattern automatically when configured.
Closest to 'simple parameterised fix' (e3). The quick_fix states: strip newlines from user data before logging, or switch to structured logging with Monolog/JSON handler. This is a small, repeatable fix pattern applied wherever user input is logged — not a single one-liner across the whole codebase, but also not a cross-cutting architectural refactor. It requires identifying and patching multiple logging call sites.
Closest to 'localised tax' (b3). Log injection applies to web, cli, and queue-worker contexts, so it touches multiple entry points, but it is fundamentally a logging concern. Once structured logging or a sanitisation helper is in place, the ongoing burden is modest. It does not reshape the architecture or impose a persistent productivity tax on unrelated work streams.
Closest to 'serious trap' (t7). The misconception field explicitly states that developers believe log injection is 'only a cosmetic issue affecting log readability.' In reality it can forge security log entries to hide breaches and, via LFI, escalate to remote code execution. This contradicts the intuitive belief that logs are inert output, making it a serious cognitive trap that experienced developers still frequently fall into.
Also Known As
TL;DR
Explanation
Log injection lets an attacker craft input containing newlines to insert fake log entries — hiding their activity or framing innocent users. It can also be used to inject terminal escape sequences that exploit log-viewing tools. Sensitive data (passwords, tokens, credit card numbers) should never appear in logs at all. Safe logging strips newlines, limits length, strips HTML tags, and redacts sensitive field names.
Common Misconception
Why It Matters
Common Mistakes
- Logging raw $_SERVER['HTTP_USER_AGENT'] or referer strings that contain newlines and control characters.
- Not stripping or escaping newline characters from all values before writing to log files.
- Using log injection to create fake entries in security logs to obscure a breach.
- Including user-supplied email addresses or usernames in log output without sanitisation.
Code Examples
// User input written directly to log — attacker forges log entries
$user = $_GET['username'];
error_log("Login attempt for user: $user");
// ?username=admin%0aINFO: Login successful for admin// Sanitise newlines before logging user-supplied values
$user = str_replace(["\r","\n","\t"], ' ', $_GET['username'] ?? '');
// Better: structured logging — each field is JSON-encoded
$logger->info('Login attempt', [
'username' => $user, // newlines harmless inside JSON string
'ip' => $request->ip(),
]);