Understanding OWASP Top 10 - A10: Server-Side Request Forgery (SSRF) Explained

Where Can We Find It?

SSRF occurs when a web application allows an attacker to send crafted requests from the server to internal or external resources. Commonly found in:

• Web applications with URL fetching (e.g., fetching metadata, webhooks)

• Cloud environments (accessing internal cloud services)

• APIs & microservices (internal API calls without validation)

---

How It Works?

Attackers exploit SSRF vulnerabilities to:
✅ Access internal systems that are not directly exposed to the internet.
✅ Retrieve sensitive data (e.g., AWS metadata, database configs).
✅ Perform port scanning on the internal network.
✅ Trigger remote code execution (RCE) in some cases.

💀 Example 1: Exploiting a Cloud Metadata API

• A web app allows users to input a URL to fetch data.

• An attacker enters:

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

  (This is the AWS metadata service that contains sensitive cloud instance details.)

• The server blindly fetches the URL, exposing sensitive credentials.

• Fix: Restrict requests to internal/private IPs and enforce allow-lists.

💀 Example 2: Bypassing Firewall Restrictions

• A banking app allows users to check if a URL is valid by making a request.

• An attacker inputs:

    http://localhost:3306
  

  (This checks if a MySQL database is running internally.)

• If the request succeeds, the attacker knows the database is exposed.

• Fix: Implement input validation and block requests to internal IP ranges.

---

Common Types of SSRF Attacks

1️⃣ Basic SSRF (Fetching Internal Resources)

• Example: Sending requests to internal services like Redis, MySQL, or localhost.

• Fix: Block internal IP ranges (127.0.0.1, 10.0.0.0/8, 192.168.0.0/16).

2️⃣ Blind SSRF (No Direct Response but Action is Executed)

• Example: Requesting a URL that triggers an internal action, like a webhook execution.

• Fix: Log and monitor outgoing requests for suspicious patterns.

3️⃣ SSRF to Remote Code Execution (RCE)

• Example: Fetching internal admin panels or code execution endpoints.

• Fix: Restrict server-side request capabilities to trusted domains only.

4️⃣ DNS Rebinding Attack via SSRF

• Example: Attacker tricks the server into resolving a domain to an internal IP.

• Fix: Validate DNS responses and restrict internal network access.

---

How to Mitigate SSRF Attacks?

✅ 1. Implement an Allow-List for Outbound Requests

• Only allow requests to trusted domains/IPs.

• Deny requests to internal/private IP ranges (127.0.0.1, 10.0.0.0/8, etc.).

✅ 2. Block Direct Access to Internal Services

• Use firewall rules to prevent public access to internal APIs & metadata services.

• For AWS, enable IMDSv2 (Instance Metadata Service) to block SSRF attacks.

✅ 3. Use URL Validation & Input Sanitization

• Restrict input to HTTP/HTTPS only (block file://, gopher://, ftp://).

• Validate and sanitize user-supplied URLs before making requests.

✅ 4. Monitor & Detect SSRF Attacks

• Log and analyze outgoing requests for suspicious destinations.

• Implement rate limiting to prevent automated SSRF exploitation.

✅ 5. Use Web Application Firewalls (WAFs)

• Modern WAFs can detect and block SSRF payloads.

• Examples: AWS WAF, Cloudflare WAF, ModSecurity.

---

Real-World Case Study: Capital One SSRF Attack (2019)

What Happened?

• A misconfigured AWS firewall allowed an attacker to exploit SSRF via a web application.

• The attacker accessed AWS metadata service (169.254.169.254), stealing sensitive credentials.

• They used the stolen credentials to exfiltrate over 100M customer records.

How They Fixed It?

✅ Implemented IMDSv2 (AWS Instance Metadata Service) to prevent SSRF access.
✅ Strengthened firewall rules to block internal service access.
✅ Enhanced logging & monitoring of internal API requests.

Lesson: A single SSRF vulnerability can lead to massive data breaches and cloud infrastructure compromise! 🚀