Crlf Injection in Feathersjs (Javascript)
Crlf Injection in Feathersjs with Javascript
Crlf Injection occurs when user-controlled data is written into HTTP headers without validation, allowing an attacker to inject additional header lines by supplying a carriage return (CR, \r) and line feed (\n) sequence. In Feathersjs with JavaScript, this can manifest when a service or hook dynamically sets headers based on request parameters, query strings, or payload fields. Because Feathers applications often compose multiple hooks and may copy headers from the incoming request into the response, a lack of sanitization can lead to response splitting or header smuggling.
For example, consider a custom Feathers hook that echoes a client-supplied X-Custom-Reason header into the response. In JavaScript, if the hook directly assigns context.headers['X-Custom-Reason'] to a user-provided value containing \r\n, an attacker can inject new headers such as X-Injected: 1 or manipulate caching and security headers. The server may not treat the injected lines as part of the original header value, causing the injected header to be processed separately by the HTTP layer. This behavior is not unique to Feathers but is enabled by the framework’s permissiveness around header assignment in hooks and services.
Another scenario involves query parameters used to set headers in a Feathers service. If a service reads req.query.referrer and sets it as a response header without validation, an attacker can provide https://evil.com\r\nSet-Cookie: session=attacker. Because the CRLF sequence terminates the current header line and starts a new one, the injected Set-Cookie line can create a cookie in the victim’s browser. Middleware that merges or forwards headers across services can amplify the impact, turning a local configuration oversight into a cross-service issue.
In the context of OWASP API Top 10, Crlf Injection maps to API1:2023 – Broken Object Level Authorization when header injection leads to privilege escalation, and to data exposure risks when security headers are bypassed. The unauthenticated attack surface of a Feathers API can be probed using tools that test header manipulation, and findings often include missing input validation on header-related fields. Because Feathers services are JavaScript-based, the injection payloads are straightforward string manipulations that exploit the runtime’s header handling without requiring special characters beyond CR and LF.
Javascript-Specific Remediation in Feathersjs
Remediation focuses on strict input validation and safe header assignment. Never directly assign user-controlled strings to response headers. Instead, maintain an allowlist of permitted header names and sanitize values by removing or encoding CR and LF characters. In JavaScript, you can normalize newlines by replacing \r and \n with an empty string or a safe literal, depending on the use case. For headers that require transparency, consider encoding the value (e.g., base64) rather than passing it raw.
Below is a safe Feathers hook in JavaScript that validates and sanitizes a custom header. The hook ensures that the header name is explicitly allowed and that the value contains no CRLF sequences before assignment.
const allowedHeaders = new Set(['X-Request-ID', 'X-Custom-Reason']);
function sanitizeHeaderValue(value) {
if (typeof value !== 'string') return value;
// Remove CR and LF to prevent response splitting
return value.replace(/[\r\n]/g, '');
}
function validateCrlfInjection(context) {
const { headers } = context;
for (const [key, value] of Object.entries(headers || {})) {
if (allowedHeaders.has(key)) {
context.res.setHeader(key, sanitizeHeaderValue(value));
}
}
return context;
}
// Usage in a Feathers service hook
app.service('tickets').hooks({
after: {
all: [validateCrlfInjection]
}
});
If you need to pass dynamic but structured data to a header, encode it to avoid injection. For instance, base64-encode a user-supplied string before setting it as a header value. The following example demonstrates encoding and safe assignment in a Feathers after hook.
function encodeHeaderValue(context) {
const raw = context.result?.data?.referrer || '';
const encoded = Buffer.from(raw).toString('base64');
context.res.setHeader('X-Referrer', encoded);
return context;
}
app.service('files').hooks({
after: {
all: [encodeHeaderValue]
}
});
Additionally, review any code that copies headers from the request to the response. In JavaScript, avoid patterns like Object.assign(res.headers, req.headers) without filtering. Instead, explicitly copy only necessary headers and apply the same sanitization routine. These practices reduce the risk of CRLF Injection while keeping the API behavior predictable in Feathers JavaScript applications.
Frequently Asked Questions
How can I test my Feathers API for Crlf Injection using middleBrick?
middlebrick scan <url>) or GitHub Action to integrate testing into your workflow.