Ssrf Server Side in Grape with Dynamodb

Server-side request forgery (SSRF) in a Grape API that interacts with Amazon DynamoDB can occur when an endpoint accepts a URL or host parameter and uses it to make an HTTP request, potentially reaching internal AWS metadata or other restricted services. Because DynamoDB is a managed AWS service, developers sometimes assume that backend calls are safe, but SSRF can still expose metadata and IAM-linked resources if the application forwards user-controlled input into network calls. For example, an endpoint that retrieves a DynamoDB table description might accept a region or endpoint URL from the client and pass it to an HTTP client without strict allowlisting, enabling an attacker to direct requests to the instance metadata service (169.254.169.254) or to other AWS services via the regional endpoint.

In a Grape service, a naive implementation might look like this, where a user-supplied URL is used to fetch metadata that is later combined with a DynamoDB request:

require 'json'
require 'net/http'
require 'bundler/setup'
require 'grape'

class AwsTableResource < Grape::API
  format :json

  # Risky: user-controlled uri param used to build a request
  get '/table/metadata' do
    uri = URI(params[:uri])
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    request = Net::HTTP::Get.new(uri)
    metadata_resp = http.request(request)

    # Combine metadata with DynamoDB table info
    table_name = params[:table_name] || 'default'
    dynamo_resp = fetch_dynamodb_table_description(table_name, metadata_resp.body)
    { metadata: metadata_resp.body, table: dynamo_resp }
  end

  def fetch_dynamodb_table_description(table_name, context)
    # Example using aws-sdk-dynamodb
    Aws::DynamoDB::Client.new(region: 'us-east-1').describe_table(table_name: table_name)
  rescue Aws::DynamoDB::Errors::ServiceError => e
    { error: e.message }
  end
end

If an attacker provides http://169.254.169.254/latest/meta-data/iam/security-credentials/ as uri, the backend may leak IAM credentials. Even when using the AWS SDK for DynamoDB, SSRF can manifest indirectly: if the SDK or surrounding code uses HTTP clients to resolve endpoints, user input may influence those calls. The attack surface expands when the API exposes endpoints that accept host or port parameters for DynamoDB-compatible services, such as a custom endpoint or a proxy that forwards requests. Because the scan testing performed by middleBrick targets the unauthenticated attack surface, such indirect SSRF paths—where user input influences network calls before or alongside DynamoDB calls—can be detected through input validation and data exposure checks.

middleBrick’s checks for SSRF, Data Exposure, and Input Validation are designed to surface these patterns by correlating OpenAPI specifications with runtime behavior. If your API specification defines parameters that influence HTTP destinations without strict validation, and runtime tests show that those parameters affect request targets, a finding will be reported with severity and remediation guidance.

To mitigate SSRF when working with DynamoDB in Grape, ensure that user-controlled input never reaches network construction logic. Validate and strictly allowlist any inputs that affect endpoints, hosts, or ports. Avoid passing raw user input to HTTP clients or SDK clients. Instead, use server-side configuration for AWS regions and endpoints, and keep sensitive operations server-bound.

Secure example that removes user-controlled URI usage and uses a fixed AWS region:

require 'json'
require 'bundler/setup'
require 'grape'
require 'aws-sdk-dynamodb'

class SecureDynamoResource < Grape::API
  format :json

  # Safe: no user input influences the HTTP client or endpoint selection
  get '/table/description' do
    table_name = params[:table_name]
    return { error: 'table_name is required' } unless table_name&.match?(/
\A[a-zA-Z0-9._-]+\z/)

    client = Aws::DynamoDB::Client.new(region: 'us-east-1')
    resp = client.describe_table(table_name: table_name)
    { table: resp.table }
  rescue Aws::DynamoDB::Errors::ServiceError => e
    { error: e.message }
  end
end

If you must accept a region, validate it against an allowlist and map it to a known AWS region rather than using it directly to construct endpoints:

ALLOWED_REGIONS = %w[us-east-1 us-west-2 eu-west-1]

def safe_dynamodb_client(region)
  raise 'region not allowed' unless ALLOWED_REGIONS.include?(region)
  Aws::DynamoDB::Client.new(region: region)
end

For inputs that affect hostnames or ports, enforce strict allowlisting and avoid direct concatenation with user input. Do not forward requests to user-supplied hosts or ports, and avoid using inputs that can redirect network traffic to internal services. middleBrick’s Property Authorization and Unsafe Consumption checks can help identify endpoints where host/port parameters might lead to SSRF or privilege escalation.

In CI/CD, the middleBrick GitHub Action can be configured with a risk threshold to fail builds if findings such as SSRF or weak input validation are detected, while the CLI allows local scans with middlebrick scan <url> to verify fixes before deployment.