Performing Ssrf Vulnerability Exploitation

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
• Python 3.8+ with required dependencies installed
• Appropriate authorization for any testing activities

Instructions

1. Install dependencies: pip install requests
2. Identify URL parameters in the target application that accept URLs or hostnames.
3. Test SSRF payloads:
   • Cloud metadata: http://169.254.169.254/latest/meta-data/
   • Internal services: http://127.0.0.1:port/, http://10.0.0.1/
   • Protocol handlers: file:///etc/passwd, gopher://, dict://
   • Bypass techniques: IP encoding, DNS rebinding, URL redirects
4. Analyze responses for information disclosure or internal access confirmation.
5. Generate a vulnerability assessment report.

# For authorized penetration testing and lab environments only
python scripts/agent.py --target-url https://app.example.com/fetch?url= --output ssrf_report.json

Examples

AWS Metadata SSRF

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

If the response contains AWS credentials (AccessKeyId, SecretAccessKey), SSRF is confirmed with critical impact.