Log Injection in Feathersjs with Hmac Signatures
Log Injection in Feathersjs with Hmac Signatures — how this specific combination creates or exposes the vulnerability
Log Injection in a Feathersjs service occurs when attacker-controlled data is written directly into application or audit logs without sanitization. When Hmac Signatures are used for request authentication and integrity, the signature value itself can become a source of injection if it is logged verbatim and later rendered in a log viewer or aggregated into a monitoring system that interprets newline or structured-delimiter characters as log boundaries.
Consider a Feathersjs service that validates an Hmac header and then logs the raw header for debugging:
const crypto = require('crypto');
const hmacSecret = process.env.HMAC_SECRET;
app.service('messages').hooks({
before: {
create: [context => {
const received = context.headers['x-hmac-signature'];
const expected = crypto.createHmac('sha256', hmacSecret).update(JSON.stringify(context.data)).digest('hex');
if (received !== expected) {
throw new Error('Invalid signature');
}
// Potential log injection point
context.params.log = `Hmac validated: ${received}`;
return context;
}]
}
});
If the received variable contains newline characters (e.g., an attacker sends a crafted header with embedded \n), the log entry can be split into multiple lines. This can corrupt log structure, facilitate log forging, or enable injection into log-based monitoring dashboards that treat each line as a separate event. The risk is compounded when logs are exported to systems that interpret newline or control characters as event separators, effectively turning an Hmac integrity check into an injection vector.
In a broader OWASP API Top 10 context, this aligns with the Security Logging and Monitoring Failures category. An attacker may attempt to obfuscate malicious activity by injecting crafted newline or JSON-like payloads into the Hmac signature field, aiming to evade detection or trick SIEM parsers. Because Hmac signatures are often long hex strings, they may appear benign, but they remain user input and must be treated as such.
middleBrick scans this scenario as part of its Input Validation and Property Authorization checks, flagging unsafe logging practices and highlighting where attacker-controlled data reaches log sinks. The scan reports include prioritized findings with remediation guidance, helping developers understand how to safely handle Hmac values without breaking integrity verification.
Hmac Signatures-Specific Remediation in Feathersjs — concrete code fixes
To prevent Log Injection when using Hmac Signatures in Feathersjs, ensure that any data written to logs is sanitized and that structured logging is used consistently. The key principle is to avoid concatenating raw Hmac header values into log messages and instead log safe, normalized representations.
First, sanitize the signature before logging by extracting only the safe hex characters and replacing any control characters:
const crypto = require('crypto');
const hmacSecret = process.env.HMAC_SECRET;
function sanitizeLogSignature(raw) {
if (typeof raw !== 'string') return 'invalid';
// Keep only hex characters, replace anything else
return raw.replace(/[^0-9a-fA-F]/g, '_');
}
app.service('messages').hooks({
before: {
create: [context => {
const received = context.headers['x-hmac-signature'];
const expected = crypto.createHmac('sha256', hmacSecret).update(JSON.stringify(context.data)).digest('hex');
if (received !== expected) {
throw new Error('Invalid signature');
}
// Safe logging: sanitize before writing
const safeSig = sanitizeLogSignature(received);
context.params.auditLog = `Hmac validated: ${safeSig}`;
return context;
}]
}
});
Second, prefer structured logging (e.g., JSON logs) to ensure log parsers can reliably separate fields. This prevents newline injection from splitting log entries:
app.service('messages').hooks({
before: {
create: [context => {
const received = context.headers['x-hmac-signature'];
const expected = crypto.createHmac('sha256', hmacSecret).update(JSON.stringify(context.data)).digest('hex');
if (received !== expected) {
throw new Error('Invalid signature');
}
// Structured log entry
context.params.auditLog = {
event: 'hmac_validation',
status: 'valid',
signatureSanitized: sanitizeLogSignature(received),
timestamp: new Date().toISOString()
};
return context;
}]
}
});
These changes align with OWASP API Top 10 recommendations for logging and monitoring, ensuring that Hmac-related data does not compromise log integrity. middleBrick’s checks for BFLA/Privilege Escalation and Input Validation will highlight whether logs still contain raw user input, while its Data Exposure checks verify that sensitive information is not inadvertently written to logs.
For teams using the middleBrick CLI (middlebrick scan <url>) or GitHub Action, these remediation steps help achieve a compliant scan result. The Pro plan’s continuous monitoring can alert you if future changes reintroduce unsafe logging patterns involving Hmac headers.