Dangling Dns in Grape with Hmac Signatures

A dangling DNS record occurs when a hostname (e.g., api-internal.example.com) still resolves in DNS but no longer points to a valid destination or is reassigned to an unexpected service. In a Grape API, if request validation relies on hostname-based checks or internal service routing without verifying the identity of the upstream service, an attacker who can control or influence DNS may redirect the target to a malicious host. When HMAC signatures are used to sign requests, the signature typically covers selected headers and the request body, but if the hostname is not part of the signed payload, an attacker can intercept or alter the request path after signing. The client signs a request to api-internal.example.com/some/path; the signature validates on the server side because the payload and headers match. However, due to a dangling DNS entry, the request is routed to an attacker-controlled host that presents the same hostname in TLS or responds on the same IP. If the server-side validation does not re-check the hostname or verify server identity via certificate pinning, it may accept the request context as legitimate. This mismatch between signed metadata and actual network routing creates an exploitable condition where an attacker can proxy signed requests through a malicious endpoint and potentially observe or manipulate traffic intended for a trusted service.

Grape routes are often organized around versioned APIs and namespaced endpoints, with middleware handling authentication and HMAC verification. If the HMAC verification logic in Grape confirms integrity and authenticity of the payload but does not explicitly validate the server’s hostname or enforce strict endpoint identity, an attacker who exploits a dangling DNS record can conduct a proxy or replay attack within the trusted network zone. For example, an internal service client signs a request with a shared secret, and the server verifies the signature using a method that checks headers and body but not the resolved destination. Because the signature does not cover the hostname, the attacker can route the signed request to a malicious listener that echoes or forwards it, leveraging the valid signature to bypass host-based allowlists. This is especially risky when internal APIs use subdomains to differentiate environments (staging, prod) and dangling records persist across environment changes. The combination of Grape routing, HMAC-based request integrity, and unresolved DNS creates a path where trust is misplaced, enabling unauthorized interactions and information exposure.

To detect such issues, scans include checks for unresolved or mismatched hostnames in routing and verify that HMAC validation incorporates hostname or certificate context. middleBrick’s API scans test whether endpoints validate server identity and whether dangling DNS records exist in the resolution path, flagging cases where signed requests lack hostname binding. Without binding the hostname to the signed data or enforcing strict certificate validation, HMAC signatures in Grape do not prevent redirection to malicious hosts. Remediation requires including the hostname in the signed payload or enforcing certificate pinning so that the server identity is verified independently of DNS. This ensures that even if DNS is dangling, the request context does not match the expected endpoint, and the signature will not be accepted on an unintended host.

To secure Grape endpoints when using HMAC signatures, always include the request target hostname (or a canonical service identifier) as part of the signed string. This binds the signature to the intended endpoint and prevents attackers from redirecting signed requests to dangling or malicious hosts. Below are two concrete, realistic code examples for a Grape API that implement HMAC signing and verification with hostname inclusion.

First, the client-side signing code. It constructs a canonical string that combines the HTTP method, the request path, a timestamp, a nonce, and the hostname, then computes an HMAC using a shared secret. The signature and metadata are added to headers so the server can verify them.

require 'openssl'
require 'base64'
require 'time'

def build_hmac_headers(method, path, hostname, body = '')
  shared_secret = ENV.fetch('HMAC_SHARED_SECRET')
  timestamp = Time.now.utc.iso8601
  nonce = SecureRandom.hex(16)
  # Canonical string includes hostname to bind the signature to the target host
  canonical = [method.upcase, path, timestamp, nonce, hostname, body].join("\n")
  signature = OpenSSL::HMAC.hexdigest('sha256', shared_secret, canonical)
  {
    'X-API-Timestamp' => timestamp,
    'X-API-Nonce' => nonce,
    'X-API-Signature' => signature,
    'X-API-Host' => hostname
  }
end

# Example usage
headers = build_hmac_headers('GET', '/api/v1/resource', 'api.example.com', '')
# headers now contain the signature and hostname

Second, the server-side verification code in Grape. It reconstructs the canonical string using the received hostname from the request (X-API-Host) and verifies the HMAC. It also checks that the hostname matches the expected service endpoint to prevent acceptance of requests routed via dangling DNS.

require 'openssl'
require 'base64'

class MyApi < Grape::API
  helpers do
    def verify_hmac_signature(env)
      received_signature = env['HTTP_X_API_SIGNATURE']
      timestamp = env['HTTP_X_API_TIMESTAMP']
      nonce = env['HTTP_X_API_NONCE']
      received_host = env['HTTP_X_API_HOST']
      request_body = env['rack.input'].read
      # Re-read body if needed; ensure it's available for verification
      env['rack.input'].rewind

      shared_secret = ENV.fetch('HMAC_SHARED_SECRET')
      # Canonical string must match client construction, including hostname
      canonical = [env.request.request_method, env.fullpath, timestamp, nonce, received_host, request_body].join("\n")
      expected_signature = OpenSSL::HMAC.hexdigest('sha256', shared_secret, canonical)

      # Use secure compare to avoid timing attacks
      return false unless secure_compare(expected_signature, received_signature)

      # Additional hostname validation: ensure the host matches the expected service
      expected_host = 'api.example.com'
      return false unless received_host == expected_host

      true
    end

    def secure_compare(a, b)
      return false unless a.bytesize == b.bytesize
      l = a.unpack "C#{a.bytesize}"
      res = 0
      b.each_byte { |byte| res |= byte ^ l.shift }
      res == 0
    end
  end

  before do
    error!('Unauthorized: Invalid signature', 401) unless verify_hmac_signature(request.env)
  end

  get '/api/v1/resource' do
    { status: 'ok' }
  end
end

These examples ensure that the hostname is part of the signed canonical string and explicitly validated on the server. By including the hostname, you eliminate the risk that a dangling DNS record can redirect a signed request to an unintended host without detection. For additional defense, enforce HTTPS and consider certificate pinning so that the server identity is bound to TLS certificates, further reducing the impact of DNS misconfigurations.