SSRF in Sinatra occurs when user-controlled input is passed directly to HTTP clients like RestClient, Faraday, or Net::HTTP. This allows an attacker to force the server to make requests to internal resources, such as AWS/GCP metadata endpoints (169.254.169.254), internal databases, or loopback services. If you aren't validating the destination, you're providing a free proxy for your internal network.

The Vulnerable Pattern

require 'sinatra'
require 'rest-client'
get ‘/proxy’ do
CRITICAL VULNERABILITY: Blindly fetching user-provided URL
url = params[:url]
RestClient.get(url).body
end

The Secure Implementation

To fix SSRF, you must implement a strict allow-list or use a dedicated library that prevents requests to private IP space. The secure example uses the 'ssrf_filter' gem, which resolves the hostname and validates the IP before the request is made, preventing DNS rebinding attacks and access to internal addresses (like 127.0.0.1 or 169.254.169.254). Key mitigations: 1. Deny all private/internal IP ranges. 2. Only allow specific protocols (HTTPS). 3. Use an allow-list of trusted domains if possible. 4. Ensure the client does not follow redirects to restricted IPs.

require 'sinatra'
require 'ssrf_filter'
get ‘/proxy’ do
url = params[:url]
begin
# Use ssrf_filter to prevent access to local/private IP ranges and metadata services
# It handles DNS resolution and checks against RFC1918, IPv6 local, etc.
response = SsrfFilter.get(url) do |req|
req.read_timeout = 2
end
response.body
rescue SsrfFilter::Error => e
status 403
“Blocked: #{e.message}”
rescue StandardError
status 500
“Internal Error”
end
end