Command Injection in Phoenix with Hmac Signatures

Command injection occurs when an attacker can influence shell command construction through untrusted input. In Phoenix applications that use Hmac Signatures to verify webhook origins, a common pattern is to recompute a signature using a shared secret and then execute a shell command based on payload contents. If the payload or derived values are concatenated directly into a shell command without proper sanitization, the application can be forced to execute arbitrary commands.

Consider a webhook endpoint that expects an X-Hmac-Signature header. The server recomputes the Hmac using a secret and the request body, compares the signatures, and then, based on event type, runs a system command such as reloading configuration or triggering a deployment script. If an attacker can control any part of the data that becomes part of the shell command—such as a filename, user identifier, or event type—and the comparison step does not enforce strict, constant-time verification, they may inject shell metacharacters (e.g., ;, &, |, $()) to alter the command flow.

Hmac Signatures themselves do not introduce injection; the risk arises when the verified payload is used to build shell commands. For example, an attacker might supply a crafted event type like config; rm -rf / or embed command separators into a user-controlled field that is later interpolated into an os.cmd call. Because the signature verifies integrity of the payload, the application may trust the content and pass it directly to the shell, leading to authenticated command injection.

Real-world parallels include injection chains observed in integrations that process webhook events for automation tools. The OWASP API Top 10 category '2023-A1: Broken Object Level Authorization' can intersect with injection when object identifiers are used in shell contexts. Additionally, unchecked inputs reaching system utilities can map to insecure deserialization or unsafe consumption patterns covered by middleBrick’s 12 security checks, which include Input Validation and Unsafe Consumption.

In a Phoenix scenario using Hmac Signatures, the vulnerability is not in the cryptographic comparison but in the downstream usage of the verified data. Even when the signature matches, if the application does not sanitize or strictly validate fields used in shell commands, an attacker who knows or guesses the webhook structure can exploit the trust relationship established by the Hmac verification.

To detect such combinations, scanning tools can analyze the request flow: verify that Hmac verification occurs, then trace how verified payload fields are used. If any field participates in command construction without escaping or strict allowlisting, the scan can flag a potential command injection path. middleBrick’s checks for Input Validation and Unsafe Consumption help highlight these risky data flows, while LLM/AI Security probes ensure that prompt or configuration data does not indirectly enable injection through generated code or instructions.

Remediation focuses on preventing untrusted data from reaching the shell and on ensuring robust verification patterns. The primary fix is to avoid building shell commands from any data derived from the request, even after Hmac verification. When system operations are necessary, use BEAM functions that do not invoke a shell, or if a shell is required, rigorously escape and validate every argument.

Example of a vulnerable pattern in Phoenix (Elixir) that concatenates user-influenced data into a command:

def handle_webhook(conn, params) do
  given_signature = conn.req_headers["x-hmac-signature"]
  computed = :crypto.mac(:hmac, :sha256, secret_key(), params["body"])
  if secure_compare(given_signature, computed) do
    # Unsafe: event_type may contain shell metacharacters
    System.cmd("scripts/deploy", [params["event_type"]])
    {:ok, conn}
  else
    {:error, :unauthorized}
  end
end

Issues: params["event_type"] is used directly as an argument; if it contains spaces or shell operators, it can cause unintended behavior. Even when passed as a list element, if the underlying port driver interpolates incorrectly or the value is later used in a string command, risk remains.

Safer approach: avoid shell-based commands entirely. Use Erlang/Elixir functions to perform the required actions:

def handle_webhook(conn, params) do
  given_signature = conn.req_headers["x-hmac-signature"]
  computed = :crypto.mac(:hmac, :sha256, secret_key(), params["body"])
  if secure_compare(given_signature, computed) do
    # Safe: no shell involved
    case params["event_type"] do
      "deploy" -> DeployService.run()
      "reload" -> ConfigService.reload()
      _ -> {:error, :unknown_event}
    end
    {:ok, conn}
  else
    {:error, :unauthorized}
  end
end

defp secure_compare(a, b) when byte_size(a) == byte_size(b) do
  # Constant-time comparison to avoid timing leaks
  :crypto.verify(a == b)
end
defp secure_compare(_, _), do: false

If a shell command is unavoidable, use :os.cmd with charlists and ensure strict allowlisting, and never interpolate strings:

def handle_webhook(conn, params) do
  given_signature = conn.req_headers["x-hmac-signature"]
  computed = :crypto.mac(:hmac, :sha256, secret_key(), params["body"])
  if secure_compare(given_signature, computed) do
    event_type = params["event_type"]
    # Strict allowlist
    allowed = %{"deploy" => "deploy.sh", "status" => "status.sh"}
    case Map.fetch(allowed, event_type) do
      {:ok, script} ->
        # Pass arguments as list; avoid shell interpretation
        System.cmd("/bin/sh", ["-c", "export SCRIPT=\"#{script}\" && sh \"$SCRIPT\""])
      :error -> {:error, :invalid_event}
    end
    {:ok, conn}
  else
    {:error, :unauthorized}
  end
end

Additional measures: enforce strict content validation on all fields used in any execution path, prefer BEAM-native operations over shell calls, and apply the principle of least privilege to the runtime environment. middleBrick’s Pro plan supports continuous monitoring to detect regressions where verified data might later be used in unsafe contexts, and the GitHub Action can fail builds if risky patterns are introduced.