Dns Rebinding in Grape with Bearer Tokens

DNS Rebinding is a client-side network attack that manipulates DNS responses to make a browser believe a malicious host is the same origin as a trusted one. When this technique intersects with API frameworks such as Grape and the use of Bearer Tokens for authorization, the risk is elevated because requests that should be confined to a protected origin can be redirected to an attacker-controlled endpoint while still presenting valid credentials.

In Grape, APIs are typically mounted as Rack applications and rely on HTTP headers for authentication, commonly the Authorization header with a Bearer token. A protected route may look like this:

# app/api/v1/base.rb
class Api::V1::Base < Grape::API
  format :json

  before do
    token = env['HTTP_AUTHORIZATION']&.to_s.split(' ')&.last
    halt 401, { error: 'Unauthorized' } unless token == ENV['API_BEARER_TOKEN']
  end
end

An attacker can craft a scenario where an authenticated user’s browser is tricked into making a request to the API with a valid Bearer token, but the DNS name in the request is altered after the initial connection. For example, a page served from trusted.example.com might include an image or script with a URL like https://api.trusted.example.com/v1/resource. Through DNS Rebinding, the attacker causes the browser to send this request to an attacker-controlled IP while the Authorization header still contains the valid Bearer token. Because the request appears to come from the trusted origin and includes a valid token, the Grape API may process it as legitimate, potentially allowing actions such as reading or modifying data that should be restricted.

The vulnerability is not in Bearer Tokens themselves, but in the combination of permissive CORS or lack of origin validation in the API, and the browser’s automatic inclusion of credentials (including Authorization headers) for same-origin requests. If the API does not explicitly validate the Origin or Referer headers and does not enforce strict CORS policies, the request may be accepted despite the changed destination IP. This can lead to unauthorized actions being performed on behalf of the authenticated user, such as changing settings or accessing sensitive endpoints that rely solely on token validation without additional context checks.

To understand the exposure, consider the attacker-controlled flow:

1. The victim visits a malicious site that initiates a request to https://api.trusted.example.com/v1/account/update with a valid Bearer token.
2. The DNS for api.trusted.example.com is made to point to an attacker server after the initial connection.
3. The browser sends the request with the Authorization header intact.
4. The Grape API, lacking strict origin validation, processes the request as if it originated from the trusted domain.

This highlights the need for server-side checks that cannot be bypassed by client-side network manipulations. Defenses must account for the possibility that a request with a valid Bearer token may still originate from an unexpected network path or IP address.

Securing Grape APIs against DNS Rebinding when using Bearer Tokens requires explicit validation of request origin and robust token handling. The goal is to ensure that even if a request arrives with a valid token, it is only accepted when it genuinely originates from trusted sources.

One effective approach is to validate the Origin and Referer headers on the server side. This prevents requests that appear to come from a trusted domain but are delivered via a different network path. Below is an enhanced Grape API example that incorporates origin checks alongside Bearer token validation:

# app/api/v1/base.rb
class Api::V1::Base < Grape::API
  format :json

  before do
    token = env['HTTP_AUTHORIZATION']&.to_s.split(' ')&.last
    halt 401, { error: 'Unauthorized' } unless token == ENV['API_BEARER_TOKEN']

    origin = env['HTTP_ORIGIN']
    referer = env['HTTP_REFERER']
    allowed_origin = 'https://trusted.example.com'

    halt 403, { error: 'Forbidden' } unless origin == allowed_origin || referer&.start_with?(allowed_origin)
  end
end

This middleware block ensures that the request’s origin matches the expected domain. The referer check provides an additional layer for browsers that include this header. Note that this validation must be performed after token verification to avoid leaking information about token validity through different error responses.

Another remediation strategy involves using SameSite cookie attributes and ensuring that CORS policies are strictly defined. While Grape does not handle cookies directly, API consumers should be instructed not to send credentials automatically for cross-origin requests. For APIs that serve web frontends, configuring CORS to allow only specific origins and methods reduces the attack surface:

# config/initializers/cors.rb
module Api
  module V1
    class Cors < Grape::API
      helpers do
        def cors_set_access_control_headers
          headers['Access-Control-Allow-Origin'] = 'https://trusted.example.com'
          headers['Access-Control-Allow-Methods'] = 'GET, POST, OPTIONS'
          headers['Access-Control-Allow-Headers'] = 'Authorization, Content-Type'
        end
      end

      before { cors_set_access_control_headers }
      options '*' { true }
    end
  end
end

For production deployments, consider placing an ingress controller or load balancer that enforces origin validation before traffic reaches the Grape application. This offloads security logic and ensures that malformed or malicious requests are rejected early.

Developers should also rotate Bearer tokens regularly and avoid embedding them in client-side code. Using short-lived tokens and refresh mechanisms limits the impact of token leakage. Combining these practices with origin validation makes DNS Rebinding significantly harder to exploit successfully in a Grape-based API environment.

• Does middleBrick scan for DNS Rebinding vulnerabilities in Grape APIs using Bearer Tokens?

  middleBrick performs security checks focused on authentication and authorization behaviors. While it does not simulate network-level DNS manipulation, it flags missing origin validation and improper token usage that can be exploited in scenarios like DNS Rebinding. The scanner’s Authentication and Property Authorization checks help surface these classes of issues.

• Can the GitHub Action prevent deployments that expose Grape APIs to DNS Rebinding risks?

  Yes. By integrating the GitHub Action and setting a security score threshold, builds can be automatically halted when findings related to authentication bypass or missing origin checks are detected. This ensures that risky configurations are addressed before deployment.