Command Injection in Rails with Basic Auth

Command Injection occurs when untrusted input is concatenated into system commands, allowing an attacker to execute arbitrary shell commands. In Ruby on Rails applications that use HTTP Basic Authentication, this risk can emerge when developer code passes request-derived data — such as user-controlled headers, parameters, or credentials — into shell commands via methods like system, exec, or backticks. Even when access is gated by Basic Auth, the authentication layer only verifies username and password; it does not sanitize or validate values that may later be used in shell construction.

Consider a scenario where a Rails controller uses Basic Auth to protect an endpoint and then uses a username or password value in a shell command, for example to query an external system or generate a report. If the input is not properly escaped, an attacker who knows or guesses the protected path can supply a crafted password containing shell metacharacters (e.g., $(id) or ;). Because the endpoint is protected by Basic Auth, the attacker may first obtain credentials via phishing or reuse, then leverage them to trigger the vulnerable code path. The combination of protected access and unchecked input creates a false sense of security while leaving the system open to authenticated command execution.

Real-world patterns include using Open3.capture3, IO.popen, or system with string interpolation that includes user data. Rails does not automatically sanitize these values, and developers must explicitly escape arguments. Attack techniques relevant here include classic shell metacharacter injection (e.g., &, |, &&) and attempts to chain commands. Because the vulnerability sits behind Basic Auth, it may be less visible in unauthenticated scans, but authenticated probing or manual testing can reveal insecure usage once credentials are supplied.

For reference, common CWE entries related to this pattern include CWE-78 (OS Command Injection) and, in broader API security contexts, findings may map to OWASP API Top 10:2023 Broken Object Level Authorization and Security Misconfiguration. Because middleBrick tests unauthenticated attack surfaces and supports authenticated scanning guidance, it can surface risky code paths that rely on credentials without validating or escaping input.

Remediation focuses on eliminating shell metacharacter usage and avoiding shell invocation entirely. The safest approach in Rails is to avoid the shell altogether by using native libraries or language-native APIs that do not require a shell. When shell commands are unavoidable, strict input validation and shell-safe escaping are required, and credentials used in code should never come from user-controlled sources.

Below are concrete, safe patterns for handling HTTP Basic Auth in Rails, followed by examples that demonstrate insecure vs secure command usage.

1. Use built-in authentication without shell interaction

Rails provides strong built-in mechanisms for authentication. Prefer has_secure_password with a database-backed model or use token-based strategies rather than constructing shell commands from credentials.

class User < ApplicationRecord
  has_secure_password
end

class SessionsController < ApplicationController
  def create
    user = User.find_by(email: params[:email])
    if user&.authenticate(params[:password])
      session[:user_id] = user.id
      render json: { status: 'ok' }
    else
      render json: { error: 'unauthorized' }, status: :unauthorized
    end
  end
end

2. If you must run commands, avoid interpolation and use arrays

When using system, prefer passing arguments as an array to avoid shell parsing and metacharacter interpretation. Never interpolate user input into the command string.

Insecure example (vulnerable)

username = params[:username] # attacker-controlled
system("echo #{username}") # UNSAFE: command injection

Secure example using array arguments

username = params[:username]
# Safe: no shell involved; arguments are passed directly
system('echo', username)

Secure example with explicit escaping (if shell features are required)

require 'shellwords'
username = params[:username]
# Safe: shellwords escapes metacharacters
command = "echo #{Shellwords.escape(username)}"
system(command)

3. Validate and restrict input when credentials are used in process logic

If your workflow requires invoking external tools with values derived from authenticated users, validate format strictly (e.g., whitelist allowed characters) and avoid using passwords or usernames directly in command construction.

class ReportController < ApplicationController
  http_basic_authenticate_with name: 'admin', password: 'S3curePass!', only: [:generate]

  def generate
    report_id = params[:report_id]
    # Validate report_id format before any use
    if report_id&;match?(/\"\A[a-zA-Z0-9_-]{1,30}\z\")
      # Prefer non-shell APIs; if shell is required, escape rigorously
      require 'shellwords'
      safe_id = Shellwords.escape(report_id)
      system("generate_report --id #{safe_id}")
      render plain: 'Report generated'
    else
      render plain: 'invalid report id', status: :bad_request
    end
  end
end