Crlf Injection in Restify (Javascript)

Crlf Injection occurs when user-controlled data is placed into HTTP headers without proper sanitization, allowing an attacker to inject newline characters (CRLF: \r\n). In Restify, a Node.js web framework, headers are commonly set via res.set() or res.header(). If these methods receive unsanitized input that includes \r\n, an attacker can inject additional headers or split the response body.

Example vulnerable pattern in Restify with JavaScript:

const restify = require('restify');
const server = restify.createServer();

server.get('/redirect', (req, res, next) => {
  const url = req.query.next || '/default';
  // Vulnerable: user input used directly in a header
  res.set('Location', url);
  res.send(302);
  return next();
});

server.listen(8080);

If an attacker sends next=example.com\r\nSet-Cookie: session=attacker, the header becomes two headers: Location: example.com and Set-Cookie: session=attacker. This enables header injection, session fixation, or response splitting.

In the context of an API security scan, middleBrick checks for places where dynamic values reach headers and flags inputs that contain newline characters. It maps findings to the OWASP API Top 10 (e.g., API1:2023 Broken Object Level Authorization when combined with injection) and references related attack patterns such as response splitting and HTTP header smuggling.

Why Restify and JavaScript amplify risk: JavaScript string concatenation and dynamic header assignment make it easy to pass unsanitized query or body values into headers. Without validation, \r\n sequences are interpreted by the HTTP parser as header separators, bypassing intended header boundaries. This is a server-side injection that does not require authentication if the endpoint is exposed unauthenticated, which is a scenario tested by middleBrick’s unauthenticated attack surface checks.

To remediate Crlf Injection in Restify, ensure all user-controlled data is validated and sanitized before being placed into HTTP headers. Avoid directly assigning request input to headers. Use allowlists for known-safe values or strict sanitization for dynamic inputs.

Secure code example in JavaScript with Restify:

const restify = require('restify');

function sanitizeHeader(value) {
  // Remove any CRLF characters and trim
  return value.replace(/[\r\n]+/g, '').trim();
}

server.get('/redirect', (req, res, next) => {
  const url = req.query.next ? sanitizeHeader(req.query.next) : '/default';
  // Safe: sanitized before use
  res.set('Location', url);
  res.send(302);
  return next();
});

// Example with allowlist for known paths
const allowedPaths = new Set(['/home', '/dashboard', '/profile']);
server.get('/nav', (req, res, next) => {
  const path = req.query.path;
  if (!allowedPaths.has(path)) {
    res.code(400).send({ error: 'invalid path' });
    return next();
  }
  res.set('Location', path);
  res.send(302);
  return next();
});

Additional best practices: validate URLs to prevent open redirects, use built-in validation libraries where available, and avoid concatenating strings to form header values. For broader API protection, middleBrick’s checks include Rate Limiting and Input Validation tests that can detect missing sanitization in runtime. If you use the middleBrick CLI, you can scan from terminal with middlebrick scan <url> to verify your endpoints are not vulnerable.

For teams managing multiple services, the Pro plan includes continuous monitoring and the GitHub Action to add API security checks to your CI/CD pipeline, failing builds if risk scores exceed your threshold. The Dashboard lets you track these findings and remediation progress over time.