Dns Rebinding in Grape with Dynamodb

DNS rebinding is an application-layer attack where a malicious webpage resolves a domain name to an IP address controlled by an attacker, then switches the DNS resolution to a different target—often a local or internal service—within the same browsing session. In a Ruby Grape API, if the API accepts user-controlled input that influences how data is retrieved from Amazon DynamoDB, DNS rebinding can be used to bypass network-based access controls and trick the server into making internal service calls it was not designed to expose.

Consider a Grape endpoint that accepts a table_name parameter and uses it to query DynamoDB. If the endpoint resolves a service hostname via DNS at runtime (for example, to support dynamic region resolution or to route to a backend datastore), an attacker can serve a page that causes the client (or the server in a chained request) to resolve that hostname to 127.0.0.1 or to an internal DynamoDB-compatible service. Because the server trusts the resolved address and does not validate that the target is the intended external endpoint, the request may be interpreted as an internal operation. This can lead to unauthorized data access or unsafe use of instance metadata if the server resolves internal hostnames as part of its logic.

With DynamoDB, the risk materializes when the server uses the resolved hostname to construct AWS service requests, such as signing requests to a regional endpoint. An attacker can force the server to send requests to a maliciously controlled proxy that relays them to internal AWS metadata services or to an internal DynamoDB Local instance, potentially exposing sensitive data or IAM role information. The vulnerability is not in DynamoDB itself, but in how the Grape application uses DNS resolution to determine service endpoints before issuing DynamoDB operations. Without explicit hostname allowlists or strict certificate validation, the API may inadvertently route requests to unintended internal endpoints, enabling SSRF-style lateral movement within the network.

To illustrate, a vulnerable Grape route might look like the following, where a user-supplied hostname is used to resolve and then query DynamoDB without validation:

require 'aws-sdk-dynamodb'
require 'socket'

class VulnerableResource
  include Grape::API

  get '/query' do
    host = params[:host] # user-controlled
    table = params[:table] || 'default-table'

    # Unsafe DNS resolution used to determine endpoint
    ip = Resolv.getaddress(host)
    endpoint = "https://#{ip}:443"

    client = Aws::DynamoDB::Client.new(endpoint: endpoint, region: 'us-east-1')
    resp = client.scan(table_name: table)
    resp.items
  end
end

In this example, an attacker can supply a hostname that initially resolves to a legitimate external IP but later rebinds to an internal address during the request, causing the server to interact with an unintended service. Because the scan performed by middleBrick tests unauthenticated attack surfaces, such unsafe patterns would be surfaced as findings under BOLA/IDOR and Input Validation checks, emphasizing the need for strict hostname validation and avoidance of runtime DNS-based endpoint selection.

Remediation focuses on removing runtime DNS-based endpoint selection and ensuring that all DynamoDB interactions use explicitly configured, validated endpoints. The server should never resolve hostnames supplied by users or derived from untrusted sources when constructing AWS service clients.

First, avoid using user input to derive hostnames or IPs. Instead, rely on the AWS SDK’s default credential and endpoint resolution, which respects environment variables and IAM policies safely. If custom endpoints are required (for example, to target a specific region or a mock service), validate the hostname against an allowlist and do not perform runtime DNS lookups on user data.

Safe Grape resource using DynamoDB with explicit endpoint configuration:

require 'aws-sdk-dynamodb'
require 'grape'

class SecureResource
  include Grape::API

  ALLOWED_HOSTS = ['dynamodb.us-east-1.amazonaws.com'].freeze

  helpers do
    def validated_endpoint(host)
      unless ALLOWED_HOSTS.include?(host)
        raise Grape::Exceptions::Forbidden, 'Endpoint not allowed'
      end
      "https://#{host}"
    end
  end

  get '/query' do
    table = params[:table] || 'default-table'
    host = 'dynamodb.us-east-1.amazonaws.com' # static, trusted

    endpoint = validated_endpoint(host)
    client = Aws::DynamoDB::Client.new(endpoint: endpoint, region: 'us-east-1')
    resp = client.scan(table_name: table)
    resp.items
  end
end

Additionally, enforce input validation for table names and use AWS SDK features like resource-based policies and VPC endpoints to restrict network paths. Do not concatenate user input into endpoint strings or perform DNS lookups based on request parameters. middleBrick’s checks for BFLA/Privilege Escalation and Property Authorization would highlight whether the API safely scopes DynamoDB access and validates endpoint configuration.

For development and testing, you can use DynamoDB Local with a fixed, non-DNS endpoint:

client = Aws::DynamoDB::Client.new(
  endpoint: 'http://localhost:8000',
  region: 'us-east-1',
  access_key_id: 'test',
  secret_access_key: 'test'
)

This approach removes reliance on runtime DNS and ensures that the target address is static and controlled. middleBrick’s OpenAPI/Swagger analysis can detect if endpoint templates in spec files rely on user-controlled variables that could enable rebinding, prompting developers to hardcode trusted endpoints or use secure configuration mechanisms.