Injection Flaws in Grape

Injection flaws in Grape APIs occur when untrusted data is sent to an interpreter as part of a command or query. Grape's DSL-based routing and parameter handling create specific injection vectors that developers must guard against.

The most common injection pattern in Grape APIs involves dynamic SQL construction. When building queries using string interpolation or concatenation with user-supplied parameters, attackers can manipulate the query structure. For example:

post '/search' do
  query = "SELECT * FROM products WHERE name LIKE '%#{params[:search]}%'"
  # Vulnerable to SQL injection
end

An attacker could submit search=%' OR '1'='1 to return all products or even execute destructive commands.

Grape's parameter coercion system can also introduce injection risks. When using types::DateTime or other type converters without validation, malformed inputs might bypass expected formats:

params do
  requires :start_date, type: DateTime
end
post '/events' do
  # Malicious date string could cause parsing errors or unexpected behavior
end

Another Grape-specific injection vector is header injection through dynamic response generation. When constructing responses based on user input without proper sanitization:

get '/download' do
  filename = params[:filename]
  content_type 'application/octet-stream'
  header 'Content-Disposition', "attachment; filename=#{filename}"
  # Filename could contain CRLF to inject additional headers
end

Command injection can occur when Grape endpoints execute system commands using user input. The system, exec, or backtick operators are particularly dangerous:

post '/run' do
  command = "echo #{params[:message]} | /usr/bin/analysis"
  `#{command}` # Vulnerable to command injection
end

Template injection is another concern when Grape APIs render ERB, Haml, or other templates with user-supplied content. Without proper escaping, attackers can inject template code:

get '/report' do
  template = ERB.new(params[:template_content])
  template.result(binding) # Unsafe rendering of user template
end

Object injection through Ruby's YAML.load or Marshal.load is particularly dangerous in Grape APIs that accept serialized data:

post '/import' do
  data = YAML.load(request.body.read) # Unsafe deserialization
  # Could execute arbitrary code during deserialization
end

Detecting injection flaws in Grape APIs requires both static code analysis and dynamic testing. middleBrick's scanner specifically targets Grape's unique patterns and vulnerabilities.

For SQL injection detection, middleBrick analyzes Grape endpoints that construct database queries. It identifies patterns like string interpolation within Grape blocks and tests with SQL metacharacters:

post '/users' do
  query = "SELECT * FROM users WHERE email = '#{params[:email]}'"
  # middleBrick would flag this pattern
end

The scanner automatically tests for common SQL injection payloads including single quotes, comment sequences (--, /* */), and UNION-based attacks. It verifies whether the API properly handles these inputs without altering query logic.

For command injection, middleBrick examines Grape endpoints using dangerous Ruby methods. It identifies system, backticks, exec, and Kernel.open calls with dynamic arguments:

post '/process' do
  cmd = "/bin/process #{params[:input]}"
  output = `#{cmd}` # middleBrick flags this
end

The scanner tests these endpoints with payloads like ; ls -la, | cat /etc/passwd, and && id to verify if command injection is possible.

middleBrick's YAML deserialization detection specifically targets Grape endpoints that accept YAML content. It identifies YAML.load, Marshal.load, and similar deserialization methods:

post '/data' do
  YAML.load(request.body.read) # middleBrick identifies this as high risk
end

The scanner tests these endpoints with malicious YAML payloads that attempt to instantiate arbitrary objects or execute code during deserialization.

For template injection detection, middleBrick analyzes Grape endpoints that render templates with user input. It identifies ERB, Haml, and other template engines used with dynamic content:

get '/view' do
  template = ERB.new(params[:content])
  template.result(binding) # middleBrick flags unsafe template rendering
end

The scanner tests these endpoints with template injection payloads to verify if code execution is possible through template rendering.

middleBrick also detects header injection vulnerabilities in Grape APIs by examining dynamic header construction:

get '/export' do
  disposition = "attachment; filename=#{params[:file]}"
  header 'Content-Disposition', disposition # middleBrick checks for CRLF injection
end

The scanner tests for CRLF injection by sending payloads containing %0D%0A sequences to verify if additional headers can be injected.

Securing Grape APIs against injection flaws requires using parameterized queries, input validation, and safe coding practices. Here are Grape-specific remediation strategies.

For SQL injection prevention, always use parameterized queries instead of string interpolation. Grape APIs should leverage ActiveRecord or similar ORMs:

post '/search' do
  # Safe: uses parameterized query
  results = Product.where('name LIKE ?', "%#{params[:search]}%")
  present results, with: API::Entities::Product
end

If raw SQL is necessary, use the sanitize_sql method or bind parameters:

post '/advanced_search' do
  query = "SELECT * FROM products WHERE category = ? AND price < ?"
  results = ActiveRecord::Base.connection.exec_query(query, 'SQL', [params[:category], params[:max_price]])
end

For command injection prevention, avoid using shell commands with user input. When system interaction is necessary, use Ruby's safe alternatives:

post '/process' do
  # Unsafe: command injection possible
  # `echo #{params[:text]} | /usr/bin/processor`
  
  # Safe: use Ruby libraries instead
  result = Processor.process(params[:text])
  { result: result }
end

If shell commands are unavoidable, use the multi-argument form of system or Open3.capture3 to prevent shell interpretation:

post '/run' do
  # Safe: no shell interpretation
  output, status = Open3.capture2e('/usr/bin/analysis', params[:input])
  { output: output, success: status.success? }
end

For YAML deserialization security, replace YAML.load with YAML.safe_load and specify allowed classes:

post '/import' do
  # Unsafe: YAML.load(request.body.read)
  
  # Safe: restrict to basic types only
  data = YAML.safe_load(request.body.read, permitted_classes: [Symbol, String, Integer, Float, TrueClass, FalseClass, NilClass, Time, Date])
  { success: true }
end

For template injection prevention, use template engines with auto-escaping enabled and never render user-supplied templates:

get '/report' do
  # Unsafe: ERB.new(params[:template_content])
  
  # Safe: use predefined templates with escaping
  template = ERB.new(File.read('templates/report.erb'))
  safe_data = sanitize_html(params[:data])
  result = template.result_with_hash(data: safe_data)
  { report: result }
end

Implement comprehensive input validation using Grape's parameter validation features:

params do
  requires :email, type: String, regexp: /[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,7}/
  requires :age, type: Integer, values: 0..120
  optional :file_name, type: String, regexp: /^[\-_a-zA-Z0-9]+\.(csv|txt|json)$/
end
post '/upload' do
  # Validated parameters are safe to use
end

For header injection prevention, validate and sanitize all header values before setting them:

get '/download' do
  filename = params[:filename]
  # Validate filename format
  if filename =~ /^[\-_a-zA-Z0-9]+\.(csv|txt|json)$/
    content_type 'application/octet-stream'
    header 'Content-Disposition', "attachment; filename=#{filename}"
    # Stream file content
  else
    error!('Invalid filename', 400)
  end
end