Crlf Injection in Sinatra with Bearer Tokens

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) characters into a header or status-line context. In Sinatra, route handlers often build HTTP responses dynamically, and if untrusted input is concatenated into headers or the status line without proper sanitization, an attacker can inject additional headers or perform response splitting. When Bearer Tokens are involved—in particular when the token value or related authorization logic is reflected in headers or error messages—the injection can manipulate authentication-related headers such as WWW-Authenticate, or forge new headers that appear to carry a valid token.

Consider a Sinatra app that echoes a token in a custom header for debugging or passes user-controlled values into header construction. If input validation is missing, an attacker can provide a token-like string containing \r\n to inject headers like X-Forwarded-For or set-cookie. Because Bearer authentication often relies on precise header formatting (Authorization: Bearer ), injected sequences can split the response and insert malicious headers that downstream services or clients interpret as authoritative. This can expose authentication boundaries, enable HTTP response splitting, or facilitate cache poisoning. The risk is higher when the app logs or reflects token values in headers without canonicalization, because the injected CRLF can create a second, attacker-controlled header block that bypasses expected authorization checks.

In the context of middleBrick’s 12 security checks, Crlf Injection is tested by probing endpoints that accept or reflect input in header construction, including scenarios where Bearer Tokens are part of request or response flows. The scanner checks whether newline characters in inputs can alter header boundaries and whether the framework’s default behavior inadvertently permits header injection. Because Sinatra does not inherently sanitize header values, developers must explicitly validate and encode any user-supplied data that participates in header formation, especially when tokens are involved.

To remediate Crlf Injection when working with Bearer Tokens in Sinatra, ensure that any user-controlled data used in headers or the status line is strictly validated and sanitized. Do not directly interpolate strings into headers; instead, use framework-provided helpers that enforce safe header formatting. Below are concrete, working code examples that demonstrate safe practices.

Example 1: Unsafe pattern (vulnerable)

require 'sinatra'

# Vulnerable: user input is directly placed into a header
get '/lookup' do
  token = params['token'] || ''
  # If token contains \r\n, it can inject additional headers or split the response
  response['X-Bearer-Token'] = token
  "Token received"
end

Example 2: Safe remediation using strict validation and header helper

require 'sinatra'

# Safe: validate token format and use header helper that avoids CRLF
BEARER_REGEXP = /^([a-zA-Z0-9\-._~+]+)*$/.freeze

helpers do
  def safe_bearer_token(input)
    # Reject tokens containing control characters, CR, LF, or whitespace
    return nil if input.to_s.include?("\r") || input.to_s.include?("\n")
    return nil unless input.to_s.match?(BEARER_REGEXP)
    input
  end
end

get '/lookup' do
  raw = params['token']
  token = safe_bearer_token(raw)
  if token.nil?
    status 400
    return { error: 'invalid_token' }.to_json
  end
  # Use the built-in header helper; Sinatra encodes values to prevent injection
  headers 'X-Bearer-Token' => token
  { received: token }.to_json
end

Example 3: Using Rack::Utils to escape header values

require 'sinatra'
require 'rack/utils'

# Encode and validate before setting headers
get '/auth' do
  token = params['token']
  # Reject tokens with newline or carriage return
  if token.to_s.include?("\r") || token.to_s.include?("\n")
    halt 400, { error: 'invalid_token' }.to_json
  end
  # Rack::Utils.encode_www_form_component can help, but for headers prefer strict allow-list
  headers 'Authorization' => "Bearer #{token}"
  { status: 'ok' }.to_json
end

General mitigation guidelines

• Never concatenate user input directly into headers or the status line.
• Use an allow-list regex to validate Bearer token characters (alphanumeric, plus safe symbols like -._~+).
• Reject or sanitize carriage returns and line feeds explicitly; do not rely on framework auto-escaping.
• Set headers using Sinatra’s headers helper or response['Header-Name'] with already-sanitized values.
• Log and monitor for sequences containing \r or \n in authorization-related parameters as part of intrusion detection.

By combining strict input validation with Sinatra’s header-setting helpers, you prevent Crlf Injection while maintaining correct Bearer Token handling. This approach ensures that authentication headers remain intact and that response splitting attacks are not possible through user-controlled token values.