🛡️OWASP 10 : Server-Side Request Forgery (SSRF)

The Hidden Gateway for Attackers

Server-Side Request Forgery (SSRF) occurs when an attacker tricks a server into making unauthorized requests on its behalf. Unlike many other attacks, SSRF targets internal systems that are often not directly exposed to the internet—making the impact severe.

This blog post explores what SSRF is, the different types, real-world examples, and practical recommendations to defend against it.

What is Server-Side Request Forgery?

SSRF happens when a web application fetches remote resources without validating the user-supplied URL. Attackers can abuse this to:

• Access internal services (databases, cloud metadata endpoints).

• Scan internal networks.

• Exfiltrate sensitive data.

• Bypass firewalls and security controls.

In simple terms: SSRF turns your server into an attacker’s proxy.

Types of SSRF

1. Basic SSRF

   • Directly manipulate a URL parameter to make the server request an attacker-controlled domain.

2. Blind SSRF

   • The attacker cannot see the response directly, but the request still reaches the internal system (e.g., used for port scanning).

3. Semi-Blind SSRF

   • The attacker cannot view the full response but can observe side effects (like DNS lookups, logs, or error messages).

4. SSRF to Cloud Services

   • Targeting cloud metadata services (e.g., AWS) to steal IAM credentials and tokens.
     

Real-World Examples

• Capital One Breach (2019):Attackers exploited SSRF to access AWS metadata services and stole sensitive information from over 100 million customers.

• GitHub Actions SSRF (2020):Misconfigured workflows allowed attackers to perform SSRF attacks against internal GitHub infrastructure.

• Alibaba Cloud SSRF (2019):Attackers abused SSRF in cloud services to gain access to internal APIs and metadata.
  

Recommendations to Prevent SSRF

1. Validate and Sanitize User Input

   • Whitelist only trusted domains.

   • Block private IP ranges (e.g., 127.0.0.1, 10.x.x.x, 169.254.x.x).

2. Restrict Server Requests

   • Limit outgoing network requests to only what is required.

   • Use firewalls to block internal and sensitive endpoints.

3. Disable Unnecessary Protocols

   • Only allow https for external communication. Block file://, ftp://, gopher://, etc.

4. Use Metadata Service v2 (for Cloud)

   • For AWS and other cloud providers, enable Instance Metadata Service v2 (IMDSv2) which requires session-based authentication.

5. Apply Least Privilege

   • Ensure services running with request capabilities have minimal permissions.

6. Monitoring & Logging

   • Log and monitor outgoing requests.

   • Set up alerts for unusual access attempts to internal or cloud endpoints.
     

Final Thoughts

SSRF is a critical vulnerability because it provides attackers with a stepping stone into internal networks that are usually protected. The Capital One breach proved that SSRF can cause massive financial and reputational damage.

The best defense is restricting what servers can request, validating user input, and applying strict network segmentation.

In short: Don’t let your server become an attacker’s mole inside your infrastructure.