SSRF Attack — When the Server Becomes the Attacker | CAISD

SSRF Attack — When the Server Becomes the Attacker | CAISD

Tags:

ssrf
cybersecurity
bugbounty
aws

Body:

*By Bamdad Shahabi | CAISD Cyber Security*
*CWE-918 · OWASP Top 10 A10*
*youtube.com/@CAISD_Official*

---

SSRF requires no credentials. No malware. No special access.
Just a URL input and a server with the wrong trust model.

This is how Capital One lost 100 million records.
This is CWE-918. This is OWASP Top 10 A10.

---

## What is SSRF?

Server-Side Request Forgery forces a web application
to make HTTP requests to arbitrary destinations —
internal cloud metadata, databases, secrets manager.

The attacker never touches internal systems directly.
They instruct the server — trusted by the network —
to do it for them.

---

## How the attack works

Normal request

POST /api/document-import
url = "https://files.example.com/report.pdf"

SSRF payload — pivots to AWS metadata

POST /api/document-import
url = "http://169.254.169.254/latest/meta-data/
iam/security-credentials/ec2-role"

**Step 1 — Discovery**
Attacker finds a URL input feature.
Document import, webhook, URL preview, PDF rendering.

**Step 2 — Injection**
Supplies 169.254.169.254 — the AWS EC2 
Instance Metadata Service (IMDS).

**Step 3 — Credential harvest**
Server queries endpoint.
IAM role credentials returned in plain JSON.

**Step 4 — Lateral movement**
Stolen keys used to enumerate S3 buckets,
access Secrets Manager, escalate privileges.

---

## Real-world: Capital One (2019)

A misconfigured WAF accepted a malicious request.
WAF queried the EC2 metadata endpoint.
IAM credentials returned. Overly permissive role.
100 million customer records exfiltrated from S3.
Cost: $190 million in settlements.

---

## Cloud metadata endpoints

AWS EC2

http://169.254.169.254/latest/meta-data/iam/
security-credentials/ROLE

GCP

http://metadata.google.internal/computeMetadata/v1/
instance/service-accounts/default/token

Azure

http://169.254.169.254/metadata/identity/oauth2/
token?api-version=2018-02-01

The attacker cannot reach 169.254.169.254 directly.
The application server can.
That asymmetry is the entire attack surface.

---

## Bug bounty severity

| Scenario | Severity |
|----------|----------|
| SSRF to AWS metadata endpoint | P1 Critical |
| IAM credential harvest via IMDS | P1 Critical |
| Internal service discovery | P2 High |
| Blind SSRF via timing/DNS | P2 High |

---

## Defense in depth

**Layer 1 — URL allowlist**
Resolve URL to IP before fetching.
Reject RFC1918 ranges: 10.x, 172.16-31.x,
192.168.x, 169.254.x.x

**Layer 2 — IMDSv2 enforcement**
AWS IMDSv2 requires PUT request before GET.
Simple GET-based SSRF receives HTTP 401.
Set HttpTokens: required on all EC2 instances.

**Layer 3 — Egress firewall**
Block outbound connections to internal CIDR ranges
at network level — independent of application code.

**Layer 4 — Least-privilege IAM**
If credentials are stolen — attacker gains nothing.
Scope EC2 role to minimum required permissions.

> Defense-in-depth means assuming each layer
> will eventually fail. SSRF is fully mitigated
> only when credential theft grants no
> meaningful access.

---

## Vulnerable patterns to watch

- Document or image import by URL
- Webhook URL configuration
- URL preview or screenshot service
- PDF generation from URL
- Server-side proxy endpoints

---

## What is CAISD?

CAISD (Cyber Intelligence & Digital Forensics)
by Bamdad Shahabi — cinematic visualizations of
XSS, SSRF, CSRF, session hijack, OWASP Top 10.

*"Making cybersecurity impossible to misunderstand."*

---

📺 youtube.com/@CAISD_Official
📄 medium.com/@mahone0094
💼 linkedin.com/in/bamdad-95a40b312
🎵 tiktok.com/@caisd_0
🐙 github.com/tiztac093/CAISD-XSS-Visual