SSRF Vulnerability Example: A Pentester's Guide to Exploitation

A Server-Side Request Forgery (SSRF) vulnerability occurs when a web application fetches a remote resource without properly validating the user-supplied URL, allowing an attacker to coerce the server into making unauthorized requests to internal or external systems. A common ssrf vulnerability example involves an attacker targeting the local loopback interface (127.0.0.1) to access admin panels or hitting cloud metadata services like 169.254.169.254 to steal IAM credentials. By manipulating these requests, security researchers can bypass firewalls and interact with services that were never intended to be public-facing.

In the world of modern application security, SSRF has climbed the ranks of the OWASP Top 10 because our infrastructure is more interconnected than ever. We aren't just dealing with simple "fetch an image" features anymore; we are dealing with webhooks, PDF generators, and cloud-native microservices that constantly talk to each other. If you can control the destination of those conversations, you control the keys to the kingdom.

Understanding the Mechanics of an SSRF Vulnerability Example

To understand how an SSRF vulnerability example works in a real-world scenario, you have to look at the trust relationship between the application server and the internal network. Most organizations have a "hard shell, soft center" security model. The external firewall is tight, but once you are inside the network, services often trust each other without much authentication.

Consider a feature where a user provides a URL for a profile picture, and the server downloads it to resize it. The backend code might look something like this in Python:

import requests

def download_profile_pic(user_url):
    response = requests.get(user_url)
    # Process the image...

An attacker doesn't provide a link to a JPG. Instead, they provide http://127.0.0.1:8080/admin. Because the request originates from the server itself, the internal admin panel sees a request coming from "localhost" and may grant full access without a password. This is the essence of SSRF: leveraging the server's identity and network position to perform actions the attacker couldn't do directly.

Key Takeaway: SSRF isn't just about reading data. It's about using the vulnerable server as a proxy to attack other systems that trust it, effectively turning the target into a "jump box" for your exploitation.

If you're just starting out, checking out a Bug Bounty for Beginners guide can help you understand where these features usually hide in modern web apps.

Basic vs. Blind SSRF

We generally categorize SSRF into two main types based on the feedback the attacker receives:

• Basic SSRF: The server returns the response from the internal resource directly to the attacker. For example, if you request http://internal-service/config.xml, the content of that file appears in your browser.
• Blind SSRF: The server makes the request, but you don't see the response body. You might only see a change in response time, a "Success/Fail" message, or an entry in your DNS logs. Exploiting this requires out-of-band (OOB) techniques.

Common Attack Vectors and Payloads

When searching for an ssrf vulnerability example, certain endpoints are more prone to this flaw. Look for parameters like ?url=, ?file=, ?image=, ?api=, or ?webhook=. Once you find a potential injection point, the next step is choosing the right payload for the environment.

Cloud Metadata Services

The "Holy Grail" for bug bounty hunters is the cloud metadata endpoint. If an application is hosted on AWS, GCP, or Azure, it likely has access to a specific internal IP address that provides information about the instance. This information often includes temporary API keys and IAM roles.

For AWS, a payload like http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role could return the AccessKeyId, SecretAccessKey, and Token needed to take over the entire cloud environment. I've seen reports where a simple SSRF in a PDF generator led to a full compromise of a company's production S3 buckets.

Internal Port Scanning

Even if you can't reach a metadata service, SSRF allows you to map the internal network. By sending requests to different ports on 127.0.0.1 or internal IP ranges (like 10.0.0.0/8 or 192.168.0.0/16), you can identify running services. A difference in error messages (e.g., "Connection Refused" vs "Timeout") tells you if a port is open. This is a fundamental part of a Web Application Security Testing Guide workflow.

Advanced SSRF: Bypassing Filters and Blacklists

Developers rarely leave SSRF vulnerabilities wide open. They usually implement blacklists to block strings like "127.0.0.1" or "localhost". However, these filters are often fragile. As a pentester, your job is to find the cracks in these defenses.

Alternative IP Formats

WAFs (Web Application Firewalls) often look for the standard dotted-decimal notation. You can bypass many of these filters by converting the IP address into other formats that the underlying OS or programming language will still resolve correctly.

• Decimal Encoding: http://2130706433/ (translates to 127.0.0.1)
• Octal Encoding: http://017700000001/
• Hexadecimal Encoding: http://0x7f000001/
• Shortened IP: http://127.1/ or http://0/

DNS Rebinding Attacks

If a developer implements a check that resolves the domain name before making the request, you can use DNS Rebinding. You control a domain (e.g., evil.com) and set its TTL to 0. The first time the server checks the IP, your DNS server returns a safe, public IP. The second time the server actually fetches the content, your DNS server returns 127.0.0.1. The application thinks it's talking to evil.com, but it's actually hitting its own internal loopback.

URL Schema Manipulation

SSRF isn't limited to HTTP/HTTPS. Depending on the library used (like cURL), you might be able to use other schemas to read local files or interact with other protocols:

file:///etc/passwd
dict://127.0.0.1:11211/stat
gopher://127.0.0.1:6379/_SET%20test%20success

Gopher is particularly dangerous because it allows you to send raw TCP data, making it possible to attack Redis, Memcached, or even SMTP servers via SSRF. Mastering these payloads is a key skill highlighted in our Burp Suite Tutorial for Pentesters.

Real-World Case Study: From SSRF to Remote Code Execution (RCE)

In a recent engagement, I encountered a web application that allowed users to import data from a remote URL. The application had a blacklist preventing the use of 127.0.0.1 and 169.254.169.254. However, it did not block the 0.0.0.0 address, which on Linux systems often maps to localhost.

By using http://0.0.0.0:6379, I confirmed that a Redis instance was running internally without a password. Using the Gopher protocol, I was able to issue commands to Redis to write a PHP web shell into the web root directory. The steps looked like this:

1. Identify the SSRF entry point in the "Data Import" feature.
2. Test for internal services using port scanning via the SSRF vulnerability.
3. Discover Redis on port 6379.
4. Craft a Gopher payload to change the Redis dbfilename to shell.php and set the dir to /var/www/html/.
5. Execute the request, creating a persistent backdoor.

Key Takeaway: SSRF is often just the "entry point." The real impact comes from what you can reach once you're inside the perimeter. Always look for unauthenticated internal services like Redis, Docker APIs, or Jenkins.

Tools and Techniques for Finding SSRF

Finding SSRF manually can be tedious, but several tools make the process more efficient. Most professional pentesters rely on a combination of automated scanning and manual verification.

Burp Collaborator

Burp Collaborator is the gold standard for detecting Blind SSRF. It provides a unique domain that you can plug into potential injection points. If the target server makes a DNS or HTTP request to that domain, Burp Suite logs it, proving that the server is vulnerable to SSRF. This is an essential technique covered in our Burp Suite Tutorial.

SSRFmap

SSRFmap is an open-source tool designed to automate the exploitation of SSRF vulnerabilities. It allows you to provide a request file and then automatically tests for different bypasses and attempts to interact with common internal services (like Redis or AWS metadata).

Interacting with Internal Services

If you find an SSRF but can't see the output, you can still use it to trigger actions. For example, if there is an internal Jenkins server, you might be able to trigger a build that executes a reverse shell. For more on handling shells, see our Reverse Shell Cheatsheet.

Remediation Strategies: How to Fix SSRF

Fixing SSRF is harder than it looks because blacklisting is almost always a losing game. Attackers are creative, and there are too many ways to represent an IP address or bypass a string check.

1. Implement a Whitelist

Instead of blocking "bad" URLs, only allow "good" ones. If your application only needs to fetch images from https://trusted-s3-bucket.amazonaws.com, then the code should verify that the user-provided URL starts with that exact string. This is the single most effective defense against SSRF.

2. Validate the IP Address

After resolving the domain name, check the resulting IP address against a list of private and reserved IP ranges. If the IP resolves to 127.0.0.1, 10.x.x.x, or 169.254.x.x, the request should be aborted. Note: You must resolve the IP first to prevent DNS rebinding attacks.

3. Disable Unused Schemas

If your application only needs HTTP/HTTPS, disable support for other protocols like file://, gopher://, ftp://, or dict:// at the library level (e.g., configuring cURL options).

4. Network-Level Defenses

Use firewalls or security groups to prevent the application server from making outgoing requests to sensitive internal ports. In a cloud environment, enforce IMDSv2 (Instance Metadata Service Version 2), which requires a session token and makes SSRF exploitation significantly more difficult.

Frequently Asked Questions

What is the main difference between SSRF and CSRF?

SSRF (Server-Side Request Forgery) forces the server to make a request to an internal or external resource. CSRF (Cross-Site Request Forgery) forces a user's browser to make a request to a web application where they are currently authenticated. In SSRF, the server is the victim/proxy; in CSRF, the user's session is the target.

Can SSRF lead to Remote Code Execution (RCE)?

Yes, SSRF is often a stepping stone to RCE. By using SSRF to interact with internal management consoles, unauthenticated APIs, or services like Redis and Memcached, an attacker can often find ways to execute arbitrary commands on the server or other internal hosts.

How do I test for Blind SSRF?

The best way to test for Blind SSRF is by using an out-of-band (OOB) listener like Burp Collaborator or interactsh. You provide a URL pointing to your listener and monitor for incoming DNS or HTTP connections from the target server's IP address.

Why is 169.254.169.254 significant in SSRF?

This is a "Link-Local" address used by major cloud providers (AWS, GCP, Azure) to provide instance metadata. Accessing this IP via SSRF allows an attacker to retrieve sensitive information, including instance identity docs and temporary security credentials (IAM keys).