Injection Flaws in Sinatra

Injection flaws in Sinatra applications typically occur when user input is incorporated directly into dynamic queries, command execution, or template rendering without proper sanitization. Sinatra's minimalist DSL makes it easy to write concise code, but this simplicity can mask dangerous patterns.

The most common injection vectors in Sinatra are SQL injection through database queries and command injection via system calls. For example, this vulnerable pattern directly interpolates parameters into SQL:

get '/users/:id' do
  id = params[:id]
  @user = DB[:users].where(id: id).first
  erb :user_profile
end

While this uses parameterized queries correctly, the previous version would allow id=1 OR 1=1 to return all users. Sinatra doesn't enforce safe practices by default, so developers must be vigilant about input validation.

Command injection is another critical concern. Sinatra applications often need to execute system commands, but improper handling creates severe vulnerabilities:

get '/execute' do
  command = params[:cmd]
  %x(#{command})
end

This allows arbitrary command execution. Even seemingly safe operations like file path construction can lead to directory traversal if user input isn't sanitized:

get '/files/:filename' do
  send_file File.join('uploads', params[:filename])
end

An attacker could request ../../etc/passwd to access sensitive files. Sinatra's flexibility means these patterns appear frequently in real applications.

Detecting injection flaws in Sinatra requires examining both the application code and runtime behavior. Static analysis can identify dangerous patterns like string interpolation in database queries or system calls. Dynamic testing involves sending malicious payloads to endpoints and observing responses.

middleBrick's Sinatra-specific scanning examines your API endpoints for injection vulnerabilities without requiring access to source code. The scanner tests common injection patterns across all 12 security categories, including input validation weaknesses that could enable injection attacks.

For SQL injection detection, middleBrick attempts to identify endpoints that might be vulnerable by testing parameter manipulation. The scanner looks for responses that indicate query manipulation, such as error messages containing SQL syntax or data exposure that suggests query modification.

Command injection testing involves sending payloads designed to trigger system command execution. middleBrick's active testing includes payloads like $(id), id;, and || id to detect if commands execute on the server. The scanner also checks for timing differences that might indicate command execution.

Template injection is another concern in Sinatra applications using ERB or other template engines. middleBrick tests for XSS and template injection by injecting script tags and template syntax to see if they render unescaped. This is particularly important for applications that use user input in view templates.

The scanner provides specific findings with severity levels and remediation guidance. For example, a finding might identify that the /search endpoint is vulnerable to SQL injection via the query parameter, showing the exact payload that triggered the vulnerability and suggesting parameterized query implementation.

Remediating injection flaws in Sinatra requires adopting secure coding practices and leveraging Sinatra's built-in features. The primary defense is using parameterized queries instead of string interpolation for database operations. Sinatra works with various database libraries, each with its own safe query patterns.

For Sequel (commonly used with Sinatra), always use parameterized queries:

get '/users/:id' do
  id = params[:id]
  @user = DB[:users].where(id: id).first
  # Safe - Sequel handles parameterization
  erb :user_profile
end

This is safe because Sequel automatically parameterizes the query. For more complex queries, use Sequel's filter API:

get '/search' do
  query = params[:q]
  results = DB[:items].where(Sequel.ilike(:name, "%#{query}%"))
  # Still safe - Sequel escapes the LIKE pattern
  json results.to_a
end

For raw SQL when necessary, use Sequel's placeholder syntax:

raw_sql = "SELECT * FROM users WHERE email = ?"
user = DB[raw_sql, email].first

Command injection requires eliminating system calls or using safe wrappers. Instead of %x(#{command}), use Ruby's Open3.capture3 with argument arrays:

require 'open3'

get '/execute' do
  command = params[:cmd]
  stdout, stderr, status = Open3.capture3('echo', command)
  # Only echoes the command, doesn't execute it
  json({ stdout: stdout, status: status.exitstatus })
end

For file operations, use Ruby's path manipulation methods to prevent directory traversal:

get '/files/:filename' do
  filename = params[:filename]
  safe_path = File.expand_path(File.join('uploads', filename))
  if safe_path.start_with?(File.expand_path('uploads'))
    send_file safe_path
  else
    halt 400, 'Invalid file path'
  end
end

Input validation is crucial for all user input. Sinatra's before filters can sanitize parameters globally:

before do
  params.each do |key, value|
    params[key] = sanitize_input(value)
  end
end

def sanitize_input(input)
  return input unless input.is_a?(String)
  input.gsub(/[^a-zA-Z0-9._-]/, '')
end

For JSON APIs, use strong parameter filtering to ensure only expected fields are processed:

post '/api/users' do
  body = JSON.parse(request.body.read)
  permitted = body.slice('name', 'email', 'age')
  # Process only permitted fields
end

Finally, implement Content Security Policy headers to mitigate XSS when rendering user content:

before do
  response.set_cookie('rack.session',
    { path: '/', secure: true, httponly: true, samesite: 'strict' })
  response.headers['Content-Security-Policy'] = "default-src 'self'"
end