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
- 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.

```bash
# 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.