Server-Side Request Forgery (SSRF): The Hidden Gateway to Internal Networks

 

Introduction
In the realm of web application security, Server-Side Request Forgery (SSRF) stands out as a stealthy and dangerous vulnerability. It allows attackers to exploit a server's ability to make HTTP requests on behalf of a user, potentially accessing internal resources that are not otherwise exposed to the public. SSRF can lead to serious consequences like data exfiltration, internal service discovery, and even remote code execution.

---

What is SSRF?
SSRF occurs when an application fetches a resource from a user-supplied URL or domain, and the application fails to validate or restrict the destination. Attackers manipulate the input to force the server to send requests to internal systems, cloud metadata endpoints, or unauthorized third-party servers.

Example:

GET /fetch?url=http://example.com/image.png

An attacker might change this to:

GET /fetch?url=http://localhost:8000/admin

If the server does not validate the target URL, it might allow access to internal-only systems.

---

Why Does SSRF Happen?

• Application trusts user-supplied URLs

• Lack of URL filtering or IP whitelisting

• Absence of DNS rebinding and redirect checks

• Misconfigured cloud services (e.g., AWS EC2 metadata service)

---

Real-World Incidents

• Capital One (2019): A misconfigured WAF combined with SSRF led to one of the largest data breaches affecting over 100 million customers.

• GitHub (2020): A SSRF flaw was found in GitHub's enterprise server through its webhook feature.

---

How to Find SSRF Vulnerabilities

1. Identify Request Parameters:

   • url, uri, link, image, redirect, target, callback, etc.

   • Common in features like file fetchers, webhooks, URL previews, and import functions

2. Manual Testing:

   • Input URLs like http://127.0.0.1, http://localhost, or internal IPs like http://169.254.169.254 (cloud metadata)

   • Observe server response codes, headers, or output content

3. Automated Tools:

   • Burp Suite Active Scanner (with SSRF plugin)

   • SSRFMap – a powerful SSRF exploitation tool

   • Interactsh / Burp Collaborator – for out-of-band detection

---

Tools for Testing SSRF

• Burp Suite (Pro version recommended)

• OWASP ZAP (for fuzzing URL inputs)

• SSRFmap (automates exploitation)

• Interactsh or CanaryTokens (detect blind SSRF)

---

Exploitation (Safely Explained)
Once discovered, SSRF can be exploited in various ways:

• Internal Port Scanning: Probe services on localhost or private IPs

• Exfiltrate Sensitive Info: Access services like Redis, MongoDB, or AWS metadata endpoint

• Command Injection: In rare cases, chained SSRF can lead to RCE (e.g., SSRF to Redis + misconfig = command execution)

---

Mitigation and Prevention

• Whitelist external URLs/IPs that can be fetched

• Block internal IP ranges (e.g., 127.0.0.1, 169.254.0.0/16, 10.0.0.0/8, etc.)

• Validate and sanitize user input for URL schemes and protocols

• Use metadata proxies in cloud environments with strict access controls

• Log all outbound requests and monitor for anomalies

---

Code Example: Vulnerable vs. Secure

Vulnerable PHP Code:

$url = $_GET['url'];
echo file_get_contents($url);

Secure PHP Code:

$url = $_GET['url'];
$parsed = parse_url($url);
if (!in_array($parsed['host'], ['example.com', 'cdn.example.com'])) {
  die("Invalid URL");
}
echo file_get_contents($url);

---

Conclusion
SSRF vulnerabilities are dangerous because they exploit the server's trust in user input to pivot into internal networks. With the growing adoption of microservices and cloud environments, the impact of SSRF is more critical than ever. Awareness, proper validation, and restricted access controls are your strongest defenses.

---

FAQs
Q1: Is SSRF always visible in the response?
A: No, blind SSRF may not return data directly. Use tools like Interactsh to detect such cases.

Q2: Can SSRF be found in mobile apps or APIs?
A: Yes. Any backend that fetches user-supplied URLs, even from mobile or IoT apps, can be vulnerable.

Q3: Is DNS rebinding related to SSRF?
A: Yes. SSRF + DNS rebinding can bypass some IP-based protections and access internal resources.

---

Call to Action
If this post helped you understand SSRF, please share it with your developer or security team. Subscribe to our blog for more deep dives into web application vulnerabilities, bug bounty write-ups, and ethical hacking techniques.