Command Injection in Grape with Hmac Signatures

Grape is a REST-like API micro-framework for Ruby that is often used to expose back-end services. When endpoints accept parameters that are used in system-level operations, such as invoking a shell or external command, improper handling of user input can lead to Command Injection. Adding Hmac Signatures for request authentication does not inherently prevent Command Injection; it only authenticates that the request originates from a trusted source. If a signed request includes untrusted data that is concatenated into a shell command, the signature validation may give a false sense of security while the application executes attacker-controlled strings.

Consider an endpoint that accepts a filename and uses system utilities to process it. The endpoint validates an Hmac Signature to ensure the caller is authorized, but then builds a command string using string interpolation with the user-supplied filename. An attacker who can obtain or guess a valid Hmac (for example, via a leaked secret or a compromised client) can inject additional shell commands using shell metacharacters such as ;, &&, or backticks. Because the Hmac confirms the request is authenticated, the command runs with the application’s privileges, potentially leading to remote code execution, data exfiltration, or further system compromise.

Command Injection in this context is not about breaking the Hmac algorithm; it is about the unsafe use of parameters after authentication. The signature ensures integrity and origin for the request metadata, but it does not sanitize or validate the semantics of the payload. If the API uses system commands to perform operations such as file manipulation, report generation, or compression, and those commands are constructed without proper escaping or isolation, the signed endpoint becomes a vector for arbitrary command execution.

Real-world attack patterns resemble typical Command Injection vectors outlined in OWASP API Top 10, where input validation and separation of control plane and data plane are insufficient. Even when rate limiting and authentication are enforced via Hmac, the unchecked use of user input in shell commands remains a critical risk. An attacker might attempt to chain a valid Hmac with a malicious payload to test whether the application distinguishes between authenticated identity and safe command construction.

Remediation focuses on ensuring that Hmac authentication and command construction are strictly separated. Authentication should never imply trust in the content of parameters used in system commands. The safest approach is to avoid invoking shell commands with user input entirely. If shell interaction is required, use controlled, language-native operations and strict allowlists instead of dynamic shell commands.

When you must interact with external utilities, prefer using built-in Ruby methods and avoid shell expansion. For example, use File.rename, FileUtils, or streaming libraries rather than shelling out with interpolated strings. If you must use system commands, pass arguments as an array and never concatenate user input into a command string.

The following example shows an unsafe pattern in Grape where an Hmac-validated parameter is used to build a shell command:

# Unsafe: concatenating user input into a shell command
class V1::FileResource < Grape::API
  format :json

  helpers do
    def valid_hmac?(params, signature)
      # Simplified Hmac verification for illustration
      expected = OpenSSL::HMAC.hexdigest('sha256', ENV['WEBHOOK_SECRET'], params[:filename])
      Rack::Utils.secure_compare(expected, signature)
    end
  end

  post '/process' do
    filename = params[:filename]
    signature = request.env['HTTP_X_HMAC_SIGNATURE']

    halt 401, { error: 'Invalid signature' }.to_json unless valid_hmac?(params, signature)

    # Dangerous: user input directly interpolated into shell command
    output = `cat #{filename}`
    { output: output }
  end
end

In this unsafe example, even though the request requires a valid Hmac, an attacker can inject shell commands by providing a filename such as report.txt; rm -rf /. The signature may be valid, but the command execution is unsafe.

A secure approach uses explicit argument arrays and avoids shell interpolation:

# Safe: using File.read without shell invocation
class V1::FileResource < Grape::API
  format :json

  helpers do
    def valid_hmac?(params, signature)
      expected = OpenSSL::HMAC.hexdigest('sha256', ENV['WEBHOOK_SECRET'], params[:filename])
      Rack::Utils.secure_compare(expected, signature)
    end
  end

  post '/process' do
    filename = params[:filename]
    signature = request.env['HTTP_X_HMAC_SIGNATURE']

    halt 401, { error: 'Invalid signature' }.to_json unless valid_hmac?(params, signature)

    # Safe: no shell, controlled file operation
    file_path = File.join('/safe/directory', File.basename(filename))
    halt 403, { error: 'Invalid filename' } unless File.exist?(file_path)

      if File.readable?(file_path)
        output = File.read(file_path)
        { output: output }
      else
        halt 500, { error: 'Unable to read file' }
      end
    end
  end
end

For cases where external commands are unavoidable, use system with an array to avoid shell interpretation:

# Safer: using system with arguments array
cmd_result = system('cat', File.basename(filename))

Even better, use Ruby’s built-in libraries to perform the operation directly, eliminating the need for a shell entirely. This approach removes the risk of Command Injection while still allowing Hmac signatures to control who can invoke the endpoint.