Symlink Attack in Chi with Api Keys

A symlink attack in the context of a Chi-based API that uses API keys occurs when an attacker manipulates file system references to gain access to or overwrite files that should be isolated from their access context. Chi is a lightweight HTTP routing library for Elixir, commonly used to build web APIs. When API keys are handled naively—such as being written to files in a predictable location or used to dynamically select file paths—an attacker who can influence file paths (for example, through user-controlled parameters) may leverage symbolic links to redirect file operations.

Consider an endpoint that stores per-client configuration or logs key rotation events by writing files under a directory derived from the API key value. If the API key is used to build a file path without canonicalization, an attacker can supply a key containing path traversal sequences or leverage directory junctions to cause the application to write to an arbitrary location. By creating a symbolic link before or during the file write, the attacker can redirect the write to a sensitive file such as /etc/passwd or application configuration that contains secrets. This becomes a symlink attack because the trusted assumption that file paths are confined to a safe namespace is violated through reference manipulation.

In a black-box scan, middleBrick tests unauthenticated attack surfaces and can surface indicators of unsafe file handling patterns that may enable symlink attacks when API keys are involved. For example, if an OpenAPI spec documents an endpoint that accepts an API key and performs server-side file operations, and runtime probes reveal directory traversal or path resolution behaviors, the scanner correlates these findings. The tool’s checks include input validation and property authorization assessments, which help detect unsafe consumption of identifiers like API keys that can be abused to influence file system references.

Even when API keys are passed as headers, improper handling on the server side—such as concatenating them to base directories or using them in log paths—can expose the application. An attacker might probe endpoints with crafted keys and inspect whether responses differ based on path resolution, confirming whether symlink abuse is feasible. The presence of user-controlled input in file paths, combined with predictable naming schemes, turns API keys into a vector for path manipulation, enabling attackers to escape intended boundaries through symbolic links.

To remediate symlink risks when using API keys in Chi, ensure API keys are never used directly in file system paths. Instead, treat them as opaque identifiers and map them to safe, canonical locations via server-side indirection. Use Elixir’s built-in path utilities to sanitize and isolate file operations, and enforce strict access controls on storage directories.

Example: Safe API key handling without path concatenation

defmodule MyApp.Router do
  use Chi.Router

  # POST /rotate-key
  # Body: { "api_key": "client-supplied-key-id" }
  post "/rotate-key" do
    %{"api_key" => client_key} = json_params(conn)

    # Map the client key to a safe, server-managed file path
    safe_path = key_to_safe_path(client_key)

    case File.read(safe_path) do
      {:ok, data} ->
        # Perform rotation logic using server-controlled path
        new_data = rotate_key_in_data(data)
        File.write!(safe_path, new_data)
        send_resp(conn, 200, "Key rotated")

      {:error, :enoent} ->
        send_resp(conn, 404, "Key not found")

      {:error, reason} ->
        send_resp(conn, 500, "Server error: #{reason}")
    end
  end

  defp key_to_safe_path(client_key) do
    # Use a deterministic, server-controlled directory and a sanitized filename
    base_dir = Path.expand("~/safe_key_storage", __DIR__)
    # Ensure the directory exists and is not writable by untrusted code
    File.mkdir_p!(base_dir)

    # Hash the key to avoid any path traversal or naming issues
    hashed = :crypto.hash(:sha256, client_key)
    Base.encode16(hashed)
    |> Path.join(base_dir)
  end
end

This approach avoids concatenating raw API keys into file paths. The key_to_safe_path/1 function maps the key to a fixed directory using a cryptographic hash, ensuring the resulting path is predictable for the server but opaque to the client. It also prevents directory traversal, null byte, or symbolic link injection because the path is resolved within a controlled root.

Enforce filesystem isolation and permissions

defmodule KeyStorage do
  @storage_dir Path.expand("~/safe_key_storage", __DIR__)

  def ensure_storage do
    unless File.dir?(@storage_dir) do
      File.mkdir!(@storage_dir)
      # Set restrictive permissions (owner read/write only) where supported
      File.chmod!(@storage_dir, :rwxr------)
    end
  end

  def store_key(key_id, content) do
    key_id
    |> key_to_safe_path()
    |> then(&File.write!(&1, content))
  end

  def read_key(key_id) do
    case File.read(key_to_safe_path(key_id)) do
      {:ok, data} -> {:ok, data}
      err -> err
    end
  end
end

By ensuring the storage directory is created with restrictive permissions and never derived from user input, you reduce the risk of symlink attacks. If your deployment involves shared environments, also consider running the service with a dedicated filesystem namespace or chroot-like isolation where feasible, and avoid logging API keys or using them in dynamic log paths.

Validation and runtime checks

Use input validation to reject API keys that contain path-like patterns, even if they are hashed before use. For extra assurance, you can add runtime checks that verify resolved paths remain within the allowed directory:

defp safe_path_within_dir?(path, dir) do
  resolved_path = Path.expand(path)
  resolved_dir = Path.expand(dir)
  String.starts_with?(resolved_path <> "/", resolved_dir <> "/")
end

This pattern ensures that even in edge cases, file operations cannot escape the intended directory. Combine this with regular security scans using tools like middleBrick to detect unsafe file handling patterns and validate that remediation effectively reduces the attack surface.