Log Injection with Hmac Signatures

Log injection in HMAC signatures occurs when untrusted data flows through cryptographic signing processes and gets logged without proper sanitization. This creates two primary attack vectors: log forgery and log poisoning.

The most common scenario involves HTTP request parameters that are part of the HMAC signing string. Consider this vulnerable pattern:

const hmac = crypto.createHmac('sha256', secret);
hmac.update(`timestamp=${timestamp}&user=${user}&action=${action}`);
const signature = hmac.digest('hex');
console.log(`Processing signature for user: ${user}`);

An attacker can inject newline characters and log formatting syntax:

user=victim%0A%09LOGGED%3A%20INJECTED%20DATA%0A%09TIMESTAMP%3A%202024-01-01

This creates forged log entries that appear legitimate:

Processing signature for user: victim
    LOGGED: INJECTED DATA
    TIMESTAMP: 2024-01-01

Another manifestation occurs in error logging during signature verification failures. When HMAC validation fails, developers often log the request data for debugging:

try {
  verifyHmac(request, secret);
} catch (error) {
  console.error(`HMAC verification failed for request: ${JSON.stringify(request)}`);
  throw error;
}

Attackers can craft requests with malicious JSON structures that break log formatting or inject control characters. The vulnerability amplifies when combined with structured logging systems that parse these logs, potentially causing log injection to affect monitoring systems, alerting rules, or SIEM correlations.

Timestamp manipulation presents another vector. HMAC signatures often include timestamps, and if these are logged directly without validation, attackers can inject log timestamps that create temporal confusion in log analysis:

timestamp=1234567890%0A%09ALERT%3A%20SUSPICIOUS%20ACTIVITY%0A%09USER%3A%20admin

The severity increases when HMAC implementations log intermediate values during the signing process, exposing partial signatures or key material if the logging system is compromised.

Detecting log injection in HMAC signature implementations requires examining both the cryptographic operations and logging patterns. Start by analyzing the HMAC signing string construction:

# Check for unsafe string concatenation in HMAC inputs
grep -r "createHmac.*update" . --include="*.js" | grep -E "(\+|=).*\$"

Look for patterns where user-controlled data flows directly into the HMAC update method without sanitization. Static analysis tools can identify these patterns, but runtime detection is more reliable.

Dynamic testing involves crafting malicious payloads that target log injection:

const maliciousPayload = {
  user: "victim\n\tLOGGED: INJECTED\n\tTIMESTAMP: 2024-01-01",r>  action: "delete"
};

Send this through your HMAC signing endpoint and monitor the logs for injection. Effective detection requires checking for:

• Newline characters (%0A, \n) in signed parameters
• Tab characters (%09, \t) that create log indentation
• Log formatting characters that could break structured logging
• Unexpected log entries appearing during HMAC operations

middleBrick's black-box scanning approach detects these vulnerabilities by testing the unauthenticated attack surface. It sends payloads containing log injection patterns to HMAC endpoints and analyzes the resulting logs for successful injection. The scanner checks 12 security categories including input validation and data exposure, specifically testing how HMAC implementations handle malicious input.

For HMAC implementations using JWT or similar token formats, check how claims are logged during verification:

const token = jwt.sign({
  sub: maliciousUser,
}, secret);

Verify that the logging system properly escapes or sanitizes all JWT claim values before logging, especially when claims contain user-controlled data.

Remediation for log injection in HMAC signatures follows defense-in-depth principles. The primary fix is input sanitization before HMAC signing and logging:

function sanitizeForLogging(input) {
  return input
    .replace(/\n/g, '')
    .replace(/\t/g, ' ')
    .replace(/\r/g, '')
    .replace(/%0A/g, '')
    .replace(/%09/g, ' ');
}

function createSecureHmac(data, secret) {
  const sanitizedData = {};
  for (const [key, value] of Object.entries(data)) {
    sanitizedData[key] = sanitizeForLogging(String(value));
  }
  
  const hmac = crypto.createHmac('sha256', secret);
  hmac.update(new URLSearchParams(sanitizedData).toString());
  return hmac.digest('hex');
}

This approach sanitizes all input before both HMAC signing and any subsequent logging. For structured logging systems, use built-in escaping mechanisms:

const log = require('structured-log');

function logHmacOperation(user, action, success) {
  log.info('HMAC operation', {
    user: sanitizeForLogging(user),
    action: sanitizeForLogging(action),
    success,
    timestamp: new Date().toISOString()
  });
}

Implement HMAC signing with canonical string construction to prevent injection through parameter ordering:

function createCanonicalHmacString(params, secret) {
  const sortedKeys = Object.keys(params).sort();
  const canonicalString = sortedKeys.map(key => {
    const value = String(params[key]);
    return `${key}=${value}`;
  }).join('&');
  
  return crypto.createHmac('sha256', secret)
    .update(canonicalString)
    .digest('hex');
}

This prevents attackers from manipulating parameter order to affect log output. For high-security applications, implement HMAC logging with redaction:

function logHmacWithRedaction(data, message) {
  const redactedData = Object.fromEntries(
    Object.entries(data).map(([key, value]) => [
      key,
      typeof value === 'string' ? value.replace(/./g, '*') : value
    ])
  );
  
  console.log(`${message}: ${JSON.stringify(redactedData)}`);
}

Finally, implement HMAC-specific monitoring that alerts on unusual log patterns, such as unexpected newlines or tab characters appearing in HMAC-related log entries.