Crlf Injection in Grape (Ruby)

Crlf Injection occurs when an attacker can inject a CRLF sequence (\r\n) into a header or status line, causing the header to be split and additional headers or response lines to be injected. In Grape, a Ruby-based REST API framework, this typically arises when user-controlled input is reflected in HTTP headers without proper sanitization. Because Grape builds responses using Rack, the final output is shaped by how headers are set on the env and response objects. If a developer concatenates or interpolates request data into header values, an attacker can supply \r\n to inject extra headers, such as Set-Cookie or Location, or to break out of the header block and inject an additional HTTP response line, which can enable cross-site scripting, response splitting, or cache poisoning.

In practice, this can happen when Grape resources directly use parameters in header assignments. For example, setting a custom header with user input without validation allows CRLF characters to be embedded. Rack and underlying servers may not always sanitize these values, so the malicious payload is passed through to the client. The vulnerability is not in Grape itself but in how Ruby code handles and passes data to the framework’s header-setting methods. Attack patterns include injecting a newline to forge headers like X-Content-Type-Options: nosniff or to manipulate redirects. Because Grape often exposes endpoints without requiring authentication during early development, the unauthenticated attack surface is significant, and scanners like middleBrick can detect these flaws by testing header inputs with CRLF patterns.

middleBrick’s checks include input validation and response header analysis, mapping findings to OWASP API Top 10 and other compliance frameworks. A scan can identify whether user input reaches headers unescaped and whether the framework’s default behavior allows header splitting. This is particularly important in Ruby environments where developers might assume Rack or the web server will normalize line endings, which is not always the case. Understanding the interaction between Grape’s routing and Rack’s header handling is essential to prevent response splitting and injection attacks.

To remediate Crlf Injection in Grape with Ruby, ensure that any user-controlled data included in HTTP headers is strictly sanitized and that CRLF characters are either removed or percent-encoded. The safest approach is to avoid direct interpolation of request parameters into headers. Instead, use whitelisting or strict validation. Below are concrete code examples demonstrating secure practices.

First, a vulnerable pattern and its fix. The vulnerable code directly uses a query parameter in a custom header, allowing an attacker to inject \r\n:

class VulnerableResource < Grape::API
  get :set_header do
    header_value = params[:value]
    header 'X-Custom', header_value
    { message: 'ok' }
  end
end

An attacker can supply ?value=foo%0D%0ASet-Cookie:%20steal=1 to inject a new header. The fix is to strip or reject CRLF characters:

class SecureResource < Grape::API
  get :set_header do
    header_value = params[:value].to_s.gsub(/[\r\n]/, '')
    header 'X-Custom', header_value
    { message: 'ok' }
  end
end

Alternatively, use a strict allowlist for header values when possible. For dynamic values, encode them using Base64 or URL encoding to prevent injection:

class EncodedResource < Grape::API
  get :encoded_header do
    raw = params[:value].to_s
    safe = Base64.strict_encode64(raw)
    header 'X-Encoded', safe
    { message: 'ok' }
  end
end

When dealing with redirects, avoid using user input directly in the Location header. Validate and normalize URLs, ensuring they are absolute or relative within allowed paths:

class RedirectResource < Grape::API
  get :redirect do
    uri = URI(params[:url])
    raise Grape::Exceptions::ValidationErrors if uri.host.nil?
    redirect uri.to_s
  end
end

These Ruby-specific practices align with Rack expectations and help prevent header splitting. middleBrick’s scans can verify that such mitigations are in place by testing endpoints with CRLF payloads and checking whether injected headers appear in the response.