SSRF-Testing: A Pentester’s Field Manual for Server-Side Request Forgery Exploitation
Hook
While most developers worry about SQL injection and XSS, SSRF vulnerabilities are quietly giving attackers access to internal AWS metadata, Redis instances, and entire private networks—and the bypass techniques keep getting more creative.
Context
Server-Side Request Forgery (SSRF) has evolved from a niche vulnerability to a major web security threat. When an application makes HTTP requests on behalf of users without proper validation, attackers can pivot those requests to internal services, cloud metadata endpoints, or even chain them into remote code execution. The problem is that defending against SSRF is deceptively complex: simple blacklists fail against IP encoding tricks, DNS rebinding attacks bypass domain whitelists, and HTTP redirect chains can sneak past even sophisticated parsers.
The SSRF-Testing repository emerged as a practical response to this complexity. Rather than building yet another automated scanner, this repository assembles a curated collection of real-world exploitation techniques. The repository serves as both a reference guide and a testing laboratory, complete with live demo endpoints that showcase how different bypass techniques work in practice. For security researchers who understand SSRF fundamentals but need quick access to the latest parser confusion tricks or cloud-specific payloads, this repository provides a comprehensive reference.
Technical Insight
The repository’s architecture is intentionally minimal—it’s a knowledge base with utility scripts rather than a framework. The core value lies in its categorized bypass techniques and testing examples at ssrf.localdomain.pw. Let’s examine some of the most powerful techniques.
URL parser confusion remains one of the most effective bypass methods. Modern applications often validate URLs using different libraries than the ones that actually make the HTTP request, creating parsing discrepancies. Consider this payload from the repository:
http://google.com:80+&@127.88.23.245:22/#+@google.com:80/This URL exploits how different parsers handle the @ symbol (traditionally used for HTTP authentication), + characters, and fragment identifiers. Some parsers will extract google.com as the hostname during validation, while the actual HTTP client connects to 127.88.23.245:22. The repository provides six variations of this technique, each exploiting different parser edge cases. Another powerful example uses backslash normalization: http://google.com:80\\@127.88.23.245:22/ which some libraries interpret as a path separator while others treat it as a hostname delimiter.
The IP encoding utilities showcase how attackers can represent the same internal IP address in multiple formats to bypass string-matching filters. The included ip.py script generates variations like hexadecimal (0xa9.0xfe.0xa9.0xfe), octal (0251.0376.0251.0376), decimal (2852039166), and even mixed notations (0xa9.254.43518). Running python ip.py 169.254.169.254 80 www.google.com produces dozens of encoded representations that all resolve to the AWS metadata endpoint but won’t match simple blacklist regex patterns.
The live demo infrastructure demonstrates HTTP redirect exploitation across multiple dimensions. The repository hosts endpoints that combine different HTTP status codes (300, 301, 302, 303, 305, 307, 308), file extensions (jpg, json, csv, xml, pdf), and response body configurations. For example:
https://ssrf.localdomain.pw/json-with-body/301-http-169.254.169.254:80-.j.jsonThis URL returns a 301 redirect with a valid JSON response body, testing whether an application follows redirects but also parses the initial response. Some vulnerable applications will process the JSON body while simultaneously making a request to the redirect target, effectively giving attackers two exploitation primitives in one request. The /custom-30x/ endpoint takes this further by accepting query parameters for custom status codes, URLs, content types (base64 encoded), and response bodies.
DNS-based attacks represent the most sophisticated bypasses. The repository includes DNS pinning services like ssrf-169.254.169.254.localdomain.pw that resolve to internal IP addresses, bypassing hostname-based whitelists. More powerful is the DNS rebinding attack implemented in dns.py, which serves different IP addresses for successive DNS queries:
python3 dns.py 216.58.214.206 169.254.169.254 78.47.24.216 53 localdomains.pwThis launches a DNS server that initially returns the whitelisted IP 216.58.214.206 for validation checks, then switches to 169.254.169.254 for the actual request. The attack exploits the time gap between when an application validates a hostname and when it makes the HTTP request, combined with short DNS TTL values. There’s also ssrf-race-169.254.169.254.localdomain.pw for testing race conditions in multi-threaded validation systems.
The cloud-metadata.txt file provides endpoint paths for AWS, Google Cloud, Azure, DigitalOcean, and other providers. The repository also documents protocol smuggling attacks using gopher://, rtsp://, and ftp:// schemes to pivot SSRF into attacks against internal Redis, MySQL, or SMTP services. The repository includes examples like using netcat to create minimal web servers that return custom redirects, and references to using gopher payloads for Redis exploitation.
Gotcha
This repository’s greatest strength—being a curated reference rather than an automated tool—is also its primary limitation. You need substantial SSRF knowledge to use it effectively. The payloads and techniques require manual adaptation to specific targets, and the repository provides minimal guidance about which bypasses work against which frameworks or filters. A junior pentester might not understand why http://⑯⑨。②⑤④。⑯⑨｡②⑤④/ (enclosed alphanumerics) would bypass a filter when standard notation fails, or when to choose DNS rebinding over redirect chains.
The live demo infrastructure at ssrf.localdomain.pw is convenient but introduces dependency risk. If this external service goes offline or changes configuration, a significant portion of the repository’s practical testing value disappears. You can’t easily run these demos locally without replicating the Apache htaccess configurations and PHP scripts. The DNS rebinding script requires running your own authoritative DNS server with proper network configuration, which isn’t trivial for testing environments behind corporate firewalls. Additionally, the repository is primarily a collection of techniques and references rather than systematic documentation about modern defenses—it focuses on offensive techniques rather than defensive guidance.
Verdict
Use if: You’re conducting authorized penetration tests or security research and need a comprehensive reference for SSRF exploitation techniques. This repository excels as a reference guide for experienced security researchers who understand the underlying vulnerability mechanics and need quick access to parser confusion tricks, cloud metadata paths, or IP encoding variations. It’s particularly valuable when you’ve already identified an SSRF vulnerability and are working to bypass specific filters or exploit it for maximum impact. The repository provides live testing endpoints, utility scripts for IP encoding, and DNS rebinding tools that can accelerate security testing workflows. Skip if: You need an automated scanner or are just starting to learn about SSRF vulnerabilities. This isn’t a turnkey tool—it’s raw material that requires security expertise to use effectively. The repository is a collection of techniques and references rather than a structured learning resource or automated testing framework. If you’re a developer trying to understand SSRF defenses rather than exploitation, this repository won’t help you build secure applications—it’s explicitly designed as a testing resource for security researchers.
