Crlf Injection in Rails (Ruby)

Crlf Injection occurs when an attacker can inject a carriage return (CR, \r) and line feed (\n) sequence into a header or status line, causing the header to be split and additional headers or response content to be injected. In Rails applications written in Ruby, this risk arises when user-controlled input is passed directly into HTTP response construction or into lower-level socket operations without proper sanitization.

Rails uses Ruby’s Rack interface to generate HTTP responses. If a developer interpolates unsanitized parameters into headers, the status line, or the body in a way that introduces \r\n sequences, Rack may forward those values directly to the web server (e.g., Puma or WEBrick). For example, injecting \r\n into a header name or value can cause the server to treat injected text as a new header or as part of the response body, potentially bypassing intended security controls.

Ruby’s String methods like gsub or insert can inadvertently preserve injected sequences if filtering is incomplete. Developers might attempt to sanitize only \n while leaving \r, or only strip leading characters while missing mid-string injections. Attack vectors include response headers, the status line, and even locations where Ruby-generated content is reflected into HTTP messages. Inadequate input validation in controllers—especially when merging params, headers, or custom logic—creates conditions where CRLF characters reach the wire.

Because Rails often abstracts low-level socket handling, developers may assume the framework or server will neutralize problematic characters. However, without explicit validation at the point where data enters the response pipeline, Ruby strings containing \r\n can propagate through to the underlying server and be interpreted as control characters. This can enable header splitting, session fixation via injected Set-Cookie lines, or reflected content that violates the same-origin policy.

To detect this specific risk, scans should test endpoints that reflect user input into headers or status contexts using sequences like \r\nX-Injected: 1 or %0d%0a (URL-encoded CR LF). The scanner evaluates whether injected content appears unmodified in the response headers or body, indicating insufficient sanitization in Ruby code paths before the response is committed.

Remediation focuses on strict validation and canonicalization of any data that may influence HTTP messages. In Ruby, avoid inserting raw user input into headers or the status line. Instead, use Rails’ built-in abstractions and explicitly filter CR and LF characters.

Example of vulnerable code:

def show
  custom_header = params[:header_value]
  response.headers['X-Custom'] = custom_header
  render plain: "OK"
end

An attacker can supply header_value=\r\nSet-Cookie: session=hijacked to inject a new header. The fix is to strip CR and LF characters from the input before using it in headers:

def show
  custom_header = params[:header_value].to_s.gsub(/[\r\n]/, '')
  response.headers['X-Custom'] = custom_header
  render plain: "OK"
end

For the status line, avoid dynamic status messages that include user input. If you must construct a status symbol safely, map to a known set of symbols and reject anything that contains control characters:

def update
  requested_status = params[:status]
  allowed = { 'ok' => 'OK', 'not_found' => 'Not Found' }
  status = allowed.fetch(requested_status, 'OK')
  render plain: "Done", status: status
end

When logging or passing data to external libraries that may eventually write to the socket, apply the same canonicalization. In Ruby, you can define a helper to remove or replace CR/LF:

HEADER_SAFE = /[\r\n]/n
def sanitize_header(value)
  value.to_s.gsub(HEADER_SAFE, '_')
end

Use this helper wherever headers are assembled from strings that may include user input. Additionally, configure Rails’ filter parameters to avoid sensitive data leakage in logs, and rely on Rails’ default behavior for setting headers rather than constructing raw header strings when possible.

For comprehensive protection, integrate scanning into development workflows. The middleBrick CLI can be used to scan Rails endpoints from the terminal:

middlebrick scan https://yourapp.example.com/api/endpoint

In CI/CD, the GitHub Action can enforce a maximum risk score before deployment, while the MCP Server enables scanning directly from Ruby-aware coding assistants to catch header manipulations early. Continuous monitoring in the Pro plan helps detect regressions as endpoints evolve.