performing-ssrf-vulnerability-exploitation

name	performing-ssrf-vulnerability-exploitation
description	Test for Server-Side Request Forgery vulnerabilities by probing cloud metadata endpoints, internal network services, and protocol handlers through user-controllable URL parameters. Tests AWS/GCP/Azure metadata APIs (169.254.169.254), internal port scanning via HTTP, URL scheme bypass techniques, and DNS rebinding detection.
domain	cybersecurity
subdomain	security-operations
tags	["performing","ssrf","vulnerability","exploitation"]
version	1.0
author	mahipal
license	Apache-2.0
nist_csf	["DE.CM-01","RS.MA-01","GV.OV-01","DE.AE-02"]

When to Use

• When conducting security assessments that involve performing ssrf vulnerability exploitation
• When following incident response procedures for related security events
• When performing scheduled security testing or auditing activities
• When validating security controls through hands-on testing

Most Often Missed & How to Confirm

• IMDSv2 needs a token, not just a GET: on AWS, GET http://169.254.169.254/latest/meta-data/ returns 401 under IMDSv2 — but SSRF can still win if it can first send PUT /latest/api/token with the X-aws-ec2-metadata-token-ttl-seconds header. Don't conclude "not vulnerable" from a single 401; test token retrieval. Note IMDSv2's hop-limit=1 blocks proxied/container hops but not same-host SSRF.
• Other clouds use different hosts/headers: GCP/Azure metadata require a header (Metadata-Flavor: Google, Metadata: true); a plain fetch returns 403, which looks "safe" but isn't. Test header injection against the right endpoints (metadata.google.internal, 169.254.169.254/metadata/instance?api-version=...).
• gopher:// for non-HTTP pivots: when only HTTP-ish fetches are allowed, gopher://127.0.0.1:6379/_<redis-payload> or gopher://...:3306 can hit internal Redis/MySQL/SMTP. A blocked http:// does not mean other schemes are — enumerate gopher://, dict://, file://, ftp://.
• Filter bypasses: allowlist/blocklist checks are defeated by http://0x7f000001, http://127.0.0.1.nip.io, decimal IPs, [::1], open redirects on a trusted domain, and DNS rebinding (TTL-0 record flipping to 169.254.169.254 after the validation check).
• Confirm a positive signal, don't infer from timing alone: the gold standard is attributable exfiltrated data — actual IAM creds (AccessKeyId/SecretAccessKey), a returned metadata document, or an out-of-band callback (Burp Collaborator / your DNS log) proving the server made the request. Blind/time-based deltas are candidates, not confirmation. Don't conclude negative until you've tried token-based IMDSv2, alternate schemes, encoded IPs, and redirect/rebinding.

Prerequisites

• Familiarity with security operations concepts and tools
• Access to a test or lab environment for safe execution