Crlf Injection in Rails

Crlf Injection (also known as HTTP response splitting) occurs when untrusted input containing a carriage return (CR, \r) and line feed (\f) sequence is reflected into HTTP headers or the status line without sanitization. In Ruby on Rails, this typically surfaces when developer code interpolates user input into headers, redirects, or set_cookie options. Attack patterns include injecting extra headers (e.g., X-Content-Type-Options) or splitting the response to smuggle an SSRF, cross-site scripting, or cache poisoning payload.

Concrete Rails code paths where this can occur include ActionController::Base#redirect_to with a string built from params, or ActionController::Helpers#cookies#[]= when assigning user-controlled values. For example, if a controller uses redirect_to(params[:next]), an attacker can supply \r\nSet-Cookie: session=hijacked to inject a new cookie. Similarly, response.set_cookie can be abused if the value or options include unsanitized input. Even the location header in redirect_to is vulnerable when the argument is not a trusted path or URL. Rails does not sanitize these values automatically; it is the developer’s responsibility to ensure inputs are safe before they reach the header or status line.

An illustrative vulnerable controller action:

class RedirectsController < ApplicationController
  def unsafe
    redirect_to(params[:url]) # Crlf Injection risk if params[:url] contains \r\n
  end
end

Another pattern involves headers in API-mode controllers (ActionController::API), where response.headers is manipulated directly:

class Api::V1::ItemsController < ApplicationController
  def show
    custom_header = request.query_parameters[:h]
    response.headers[custom_header] = 'value' # Crlf Injection risk if custom_header includes \r\n
  end
end

These patterns are relevant to the unauthenticated attack surface tested by middleBrick, which checks for Crlf Injection among its 12 security checks. If user-controlled input reaches headers or the status line, scanning can detect whether sanitization is missing and flag the finding with severity and remediation guidance.

To identify Crlf Injection in Rails during scanning, a black-box test sends payloads containing \r\n sequences in parameters, headers, and cookies, then inspects the raw response for response splitting indicators such as an unexpected second status line, injected headers, or reflected payloads outside the intended context. middleBrick runs this as part of its parallel checks, exercising unauthenticated endpoints to surface places where user input is reflected without safe output encoding or canonicalization.

You can also perform targeted manual checks. For example, probe redirect behavior with a payload that includes a newline and carriage return:

# Using curl to test for response splitting
curl -v "http://localhost:3000/redirects/unsafe?url=https://example.com%0d%0aSet-Cookie:%20attack=1"

If the response contains two Set-Cookie lines or an injected header, the endpoint is vulnerable. In a Rails console or integration test, you can simulate the request and inspect the raw output to confirm injection:

require 'test_helper'
class CrlfInjectionTest < ActionDispatch::IntegrationTest
  test "injects crlf in redirect_to location" do
    get "/redirects/unsafe", params: { url: "https://example.com\r\nX-Contained: injected" }
    assert_response :success
    # Check that the response does not contain injected header/status
  end
end

middleBrick’s LLM/AI Security checks are unique in that they also probe endpoints that interact with language models; while Crlf Injection is not an AI-specific issue, the scanner’s broad coverage includes this class of injection across all endpoints. Using the Web Dashboard, you can track scores over time and see per-category breakdowns; the CLI provides JSON or text output for scripting, and the GitHub Action can fail builds if the score drops below your chosen threshold.

Remediation in Rails focuses on avoiding direct concatenation of user input into HTTP headers or the status line. Use path-based redirects instead of string-based ones when possible, and validate or sanitize inputs that must be used. Rails provides helpers and configuration to make this safer. For example, use redirect_to with a named route or a trusted URL helper so the framework can ensure the location is a safe path or absolute URL without room for injection:

class SafeRedirectsController < ApplicationController
  def safe
    # Use a whitelist of allowed paths or use url_for with sanitized input
    redirect_to(params[:url] =~ /^\/\w+$/ ? params[:url] : '/fallback')
  end
end

When you need to set custom headers, avoid interpolating raw input into the hash key. Instead, map known keys to sanitized values, or use Rails’ built-in helpers for common headers. For cookies, prefer the signed and encrypted cookie jars provided by ActionDispatch, and avoid constructing cookie values with user input directly:

class SafeCookiesController < ApplicationController
  def set_preference
    # Use permitted keys and sanitize the value, rather than reflecting user input as the key
    known_key = params[:key] if %w[theme locale].include?(params[:key])
    cookies[known_key] = { value: CGI.escape(params[:value]), httponly: true } if known_key
  end
end

For API-mode controllers, validate header names against a strict allowlist and ensure values are properly encoded. Rails’ default behavior does not split on \r\n, but if user input reaches the raw header map, it can corrupt the response stream. The middleBrick Pro plan includes continuous monitoring and can be configured with custom thresholds; the GitHub Action can gate CI/CD pipelines, preventing deployment when a scan exceeds your risk tolerance.

Finally, adopt defense-in-depth: use strong parameter validation, prefer symbol-based header keys where feasible, and test with integration specs that assert no unexpected line breaks appear in the raw HTTP response. These practices reduce the likelihood of Crlf Injection and complement the findings and remediation guidance provided by scanning tools.