SSRF-Testing: A Penetration Tester's Payload Arsenal for Server-Side Request Forgery Attacks
Hook
A single misconfigured HTTP request handler can let attackers pivot from a web application into internal Redis servers, cloud metadata APIs, and SMTP relays—all without ever touching your firewall. SSRF vulnerabilities turn your server into an unwitting accomplice.
Context
Server-Side Request Forgery (SSRF) has evolved from an obscure vulnerability class into one of the most critical web security threats. The 2019 Capital One breach, which exposed 100 million customer records, stemmed from an SSRF vulnerability that accessed AWS metadata endpoints. Yet despite its severity, SSRF remains notoriously difficult to test comprehensively because modern applications employ increasingly sophisticated URL parsing, validation, and filtering mechanisms.
The challenge for security researchers isn't just finding SSRF vulnerabilities—it's knowing which of the dozens of bypass techniques will work against a particular target's defenses. URL parsers behave inconsistently across languages and frameworks. A filter that blocks http://169.254.169.254 might fail against decimal IP encoding (http://2852039166), DNS rebinding, or protocol smuggling via Gopher. The cujanovic/SSRF-Testing repository emerged as a practical response to this complexity: a curated collection of real-world SSRF payloads, exploitation techniques, and live testing infrastructure that consolidates years of bug bounty findings and security research into a single reference guide.
Technical Insight
The repository's architecture reflects the multi-layered nature of SSRF exploitation, organizing attack vectors into distinct categories that target different components of the request handling chain. At its foundation are static payload collections—wordlists of IP encoding variations, URL parser abuse patterns, and protocol wrappers that can be fed into fuzzing tools or tested manually.
The ip.py utility demonstrates one of the most fundamental SSRF bypass techniques: IP address encoding manipulation. Many developers implement SSRF protections by blacklisting specific IP ranges like 127.0.0.1 or 169.254.169.254 (AWS metadata endpoint) using simple string matching. This script generates alternative representations that bypass such filters:
import socket
import struct
def ip_to_decimal(ip):
return struct.unpack("!L", socket.inet_aton(ip))[0]
def ip_to_hex(ip):
return '0x' + ''.join(['%02x' % int(i) for i in ip.split('.')])
def ip_to_octal(ip):
return '.'.join(['0%o' % int(i) for i in ip.split('.')])
# Example: 127.0.0.1
print(ip_to_decimal('127.0.0.1')) # 2130706433
print(ip_to_hex('127.0.0.1')) # 0x7f000001
print(ip_to_octal('127.0.0.1')) # 0177.0.01.0.01
These encodings exploit the fact that underlying networking libraries (like cURL's libcurl or Python's socket module) accept multiple IP representations, while application-layer filters only check for dotted-decimal notation. A request to http://2130706433/admin resolves identically to http://127.0.0.1/admin, but often bypasses naive blocklists.
The repository's most sophisticated technique involves DNS-based attacks through the dns.py script, which implements DNS rebinding using the Twisted framework. DNS rebinding exploits the time-of-check-time-of-use (TOCTOU) vulnerability in SSRF defenses that validate URLs before making requests. The attack works in two phases:
# Simplified DNS rebinding logic
class DNSRebindingResolver:
def __init__(self, safe_ip, target_ip, ttl=1):
self.safe_ip = safe_ip # First response: public IP
self.target_ip = target_ip # Second response: internal IP
self.request_count = 0
def resolve(self, domain):
if self.request_count == 0:
self.request_count += 1
return self.safe_ip # Pass validation
else:
return self.target_ip # Actual request hits internal
When an application checks if attacker.com resolves to a safe IP and then makes the actual request, the attacker's DNS server returns different IPs for each lookup. The validation sees a benign public IP, but the subsequent request resolves to 127.0.0.1 or an internal service.
The live demo infrastructure at ssrf.localdomain.pw showcases protocol smuggling—arguably the most powerful SSRF technique. The Gopher protocol, supported by cURL and many HTTP libraries, allows constructing arbitrary TCP payloads with precise control over raw bytes. This enables cross-protocol attacks where HTTP requests become SMTP commands or Redis operations:
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a
This payload, when processed by a vulnerable application using cURL, sends a Redis FLUSHALL command that wipes the entire database. The Gopher protocol bypasses HTTP-specific SSRF filters because the application validates it as a legitimate URL scheme, but the receiving service interprets the payload as native protocol commands. The repository includes similar patterns for SMTP relay abuse (sending emails through internal mail servers) and FastCGI exploitation.
Another underutilized technique documented here involves file format-based SSRF through SVG images and FFmpeg parameters. Modern applications often process user-uploaded media, and both SVG's XML parsing and FFmpeg's HLS playlist support can trigger external requests:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg">
<image height="100" width="100" xlink:href="http://169.254.169.254/latest/meta-data/iam/security-credentials/" />
</svg>
When an application validates and processes this SVG (for thumbnail generation, resizing, or display), the XML parser fetches the AWS metadata endpoint. This bypasses application-layer URL validation entirely because the SSRF vector is embedded within what appears to be legitimate image data.
The repository also catalogs "enclosed alphanumeric" characters—Unicode variants of standard ASCII characters that certain parsers normalize after validation. Characters like ⓗⓣⓣⓟ (U+24D7-24E3) might pass through a regex filter looking for http:// but get normalized to standard ASCII by the URL parser, resulting in a successful SSRF attack. These encoding tricks exploit the impedance mismatch between validation logic (often regex-based) and actual request execution (which may normalize Unicode).
Gotcha
The repository's greatest strength—comprehensiveness—is also its primary limitation. This is fundamentally a reference collection rather than an automated testing framework. You need to manually select appropriate payloads, understand why each bypass technique works, and interpret results without guidance. Unlike point-and-click vulnerability scanners, there's no workflow that says "start here, try these in order, stop when you find a working bypass." If you're new to SSRF exploitation, the sheer volume of techniques without contextual prioritization can be overwhelming.
The dependency on external infrastructure introduces reliability concerns. Several demonstration URLs rely on ssrf.localdomain.pw, which is maintained separately from the repository. During testing for this article, some endpoints were intermittently unavailable, and there's no guarantee this infrastructure will remain online indefinitely. Many referenced links point to archived versions of security blog posts or HackerOne reports, suggesting the collection suffers from link rot. The repository hasn't seen major updates recently, meaning newer SSRF techniques (like HTTP/2 request smuggling or WebSocket-based SSRF) aren't covered. You're getting a snapshot of SSRF exploitation circa 2018-2020, not a living document that tracks emerging attack patterns.
Verdict
Use if you're conducting penetration tests, bug bounty hunting, or security assessments where you suspect SSRF vulnerabilities and need a comprehensive payload database. This repository excels when you understand the underlying mechanics and need specific bypasses for stubborn filters—the IP encoding generator alone can save hours of manual payload crafting. It's particularly valuable for testing cloud environments (AWS, GCP, Azure) where metadata endpoint access represents critical risk. Skip if you're learning SSRF fundamentals and need structured tutorials with explanations, require an automated scanner with minimal configuration, or want a maintained tool with active development. Also skip if you need comprehensive defense guidance—this is an offensive security resource that assumes you'll reverse-engineer protection mechanisms from the attack patterns. For those scenarios, consider SSRFmap for more automation or academic papers on SSRF for foundational knowledge before returning to this payload collection.
