Dns Rebinding in Grape with Cockroachdb

DNS Rebinding is a client-side attack that manipulates DNS responses to make a victim’s browser believe a remote host is reachable at an attacker‑controlled address. In a Grape API, an endpoint that accepts a hostname or URL and then uses that value to open a TCP connection to a database can be abused to redirect traffic to a CockroachDB instance that is normally not reachable from the internet.

Consider a Grape resource that reads a database host from user input and attempts to connect to CockroachDB:

class DbConnectResource
  include Grape::API
  params do
    requires :host, type: String, desc: 'Database host'
    requires :port, type: Integer, default: 26257
  end
  post :connect do
    # Unsafe: directly using user-supplied host/port
    conn = CockroachRb::Client.new(
      hosts: "#{params[:host]}:#{params[:port]}",
      database: 'appdb',
      username: 'app_user',
      password: 'secret'
    )
    conn.execute('SELECT 1')
    { status: 'ok' }
  end
end

If the endpoint is exposed without network-level restrictions (for example, binding to 0.0.0.0 or allowing connections from the public internet), an attacker can register a domain that initially resolves to a benign IP, then switch the DNS to point to an internal CockroachDB listener (e.g., 127.0.0.1 or a Kubernetes service IP). The victim’s browser—perhaps authenticated to the Grape app via session cookies—will follow the rebinded IP and open a connection to the internal database.

This becomes especially dangerous when CockroachDB is configured with insecure authentication or when the connection string embeds static credentials. The attacker can then issue SQL commands, read sensitive data, or modify records depending on the database user’s privileges. Because the attack originates from the victim’s own browser, same-origin policies and network ACLs are bypassed, making server-side network segregation the primary mitigation.

middleBrick scans such endpoints as part of the Property Authorization and Input Validation checks, flagging unsafe host/port handling and missing network controls. The scanner also tests for SSRF-like behaviors that can pivot to internal services like CockroachDB, ensuring these cross-layer risks are surfaced in the report.

Remediation centers on strict input validation, network segregation, and avoiding dynamic host/port usage for database connections. Prefer configuration-driven connection strings and disallow user-controlled host resolution for database traffic.

1. Use a fixed, configuration-driven connection string

Define the CockroachDB connection parameters in environment variables or a secure configuration store, and do not concatenate user input into the connection target:

# config/initializers/cockroach.rb
require 'cockroach_rb'

COCKROACH_CLIENT = CockroachRb::Client.new(
  hosts: ENV.fetch('COCKROACH_HOSTS', 'localhost:26257'),
  database: ENV.fetch('COCKROACH_DATABASE', 'appdb'),
  username: ENV.fetch('COCKROACH_USER', 'app_user'),
  password: ENV.fetch('COCKROACH_PASSWORD', 'secret')
)

Then in your resource, use the preconfigured client:

class SafeDbResource
  include Grape::API
  get :health do
    result = COCKROACH_CLIENT.execute('SELECT 1')
    { status: 'healthy', row: result.first }
  rescue => e
    # Log the error; do not expose raw DB errors to the client
    { error: 'service unavailable' }
  end
end

2. If dynamic endpoints are required, enforce allowlists and network controls

If your design must accept a target, restrict values to a strict allowlist and enforce that the target resolves only to approved internal networks:

class ControlledDbResource
  include Grape::API
  ALLOWED_HOSTS = %w[db-internal.example.com db-replica.internal]

  params do
    requires :host, type: String, values: ALLOWED_HOSTS,
                    desc: 'Preapproved database host'
    requires :port, type: Integer, values: 26257,
                    desc: 'Fixed CockroachDB port'
  end

  post :connect_controlled do
    conn = CockroachRb::Client.new(
      hosts: "#{params[:host]}:#{params[:port]}",
      database: 'appdb',
      username: 'app_user',
      password: 'secret'
    )
    conn.execute('SELECT 1')
    { status: 'ok' }
  end
end

Additionally, ensure the API server binds to a firewall‑protected interface and does not route database traffic over user‑controlled paths. Use service mesh or mTLS where possible to protect in‑transit traffic between the API and CockroachDB.

3. Defense in depth: monitoring and middleBrick integration

Deploy runtime monitoring for unexpected outbound connections to database ports and enable audit logging in CockroachDB. middleBrick’s continuous monitoring (Pro plan) can schedule scans of your Grape endpoints and flag risky patterns such as dynamic host usage or missing network isolation, integrating findings into your GitHub Action CI/CD gates to prevent regressions.

By combining fixed configuration, strict allowlists, and active scanning, you reduce the attack surface for DNS Rebinding against CockroachDB in Grape services.