SSRF Explained: Making the Server Your Proxy

This is part 1 of a 3-part series on Server-Side Request Forgery. This part covers what SSRF is and how to identify it. Part 2 will be exploitation. Part 3 will be prevention.

The Idea

Most web vulnerabilities are about attacking the server directly — SQL injection, XSS, file uploads. SSRF is different. You're not attacking the server. You're getting the server to attack things on your behalf.

Here's the scenario. A web application doesn't work alone. Behind the scenes it's talking to other services — maybe a database, maybe an internal API, maybe a cloud provider, maybe a completely separate internal web application running on a port that's not exposed to the outside world. These services are completely invisible to you as an external user. You can't reach them directly.

But the web application can. And here's where it gets interesting.

Sometimes the URL or address that the web application uses to talk to these internal services isn't hardcoded. It's taken from user input. A parameter in the request that tells the application "go fetch this resource." The developer built it that way for flexibility — maybe the app needs to check availability from different date servers, or load content from different sources depending on context.

The moment that URL parameter is user-controlled, you control where the server makes its requests. You can point it at internal services you'd never be able to reach directly. You can make it talk to your own machine to confirm the vulnerability. You can probe the internal network. In some cases you can read local files or interact with other services entirely.

That's SSRF — Server-Side Request Forgery. You're forging requests that appear to come from the server itself.

Why It Made OWASP's Top 10

SSRF is on OWASP's Top 10 list of most critical web vulnerabilities for a good reason. The impact depends heavily on the application's setup, but it can range from useful information disclosure all the way to full internal network compromise.

A few URL schemes that make SSRF particularly dangerous:

http:// and https:// — make the server send HTTP requests. Useful for reaching internal services, bypassing WAFs, or accessing endpoints that only accept connections from internal IP addresses.

file:// — make the server read files from its own filesystem and return their contents. Essentially turns SSRF into LFI.

gopher:// — a lesser-known protocol that can send arbitrary bytes to any address. Attackers use this to send crafted HTTP POST requests, interact with databases, or communicate with mail servers.

Spotting It in the Wild

The lab for this part is an appointment scheduling application — DefendTech Innovations. You pick a date, hit "Check Availability," and the application tells you whether that slot is open.

Intercepting the request in Burp reveals something immediately interesting in the POST body:

dateserver=http://dateserver.htb/availability.php&date=2024-01-01

dateserver=http://dateserver.htb/availability.php&date=2024-01-01

There's a dateserver parameter containing a full URL. The application is fetching availability data from a separate server — and it's accepting that server's address directly from the user. That's a textbook SSRF setup.

Confirming the Vulnerability

The first thing to do with any potential SSRF is confirm it actually makes outbound requests. Start a netcat listener on your machine and point the dateserver parameter at your IP:

dateserver=http://YOUR_IP:4444/&date=2024-01-01

dateserver=http://YOUR_IP:4444/&date=2024-01-01

The server connected to our machine. We can see the incoming GET request in netcat — the server made that request, not us. SSRF confirmed.

Is It Blind or Reflected?

There are two types of SSRF. Blind SSRF is when the server makes the request but you don't see the response — you only know it happened because your listener received a connection. Reflected SSRF is when the response from whatever the server fetches comes back to you in the application's response.

Reflected is obviously more powerful. To test which we have, point the dateserver parameter at the application itself:

dateserver=http://127.0.0.1/index.php&date=2024-01-01

dateserver=http://127.0.0.1/index.php&date=2024-01-01

The full HTML source of the application came back in the response. This is reflected SSRF — the server fetched its own page and returned the content to us. We can see everything the server sees when it makes requests.

Mapping the Internal Network

With reflected SSRF, we can use the server as a port scanner against itself and anything else on its internal network. The key is finding a difference in the response between open and closed ports — if we send a request to a closed port, the server returns an error. If the port is open, we get a different response.

Generate a port list and fuzz with ffuf, filtering out responses that contain the connection error message:

seq 1 10000 > ports.txt
ffuf -w ./ports.txt \
-u http://TARGET/index.php \
-X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "dateserver=http://127.0.0.1:FUZZ/&date=2024-01-01" \
-fr "Failed to connect to"

seq 1 10000 > ports.txt
ffuf -w ./ports.txt \
-u http://TARGET/index.php \
-X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "dateserver=http://127.0.0.1:FUZZ/&date=2024-01-01" \
-fr "Failed to connect to"

Port 8000 came back with a response size of 37 — different from everything else. Something is running there. Let's fetch it directly:

dateserver=http://127.0.0.1:8000&date=2024-01-01

dateserver=http://127.0.0.1:8000&date=2024-01-01

There's a service running on port 8000 that's completely invisible from the outside — no firewall would let you reach it directly. But through the SSRF, the server fetched it for us and returned the response. Internal service, exposed through a single user-controlled URL parameter.

The Core Problem

What makes SSRF dangerous isn't the vulnerability itself in isolation — it's what sits behind it. The web application has trust relationships with internal services that you as an external user aren't supposed to have. A database that only accepts connections from the web server. An admin panel that only listens on localhost. Cloud provider metadata endpoints that return credentials when called from inside the infrastructure.

All of those trust the requests coming from the web server. When you can control what the web server requests, you inherit all of that trust.

Part 2 — exploiting SSRF to go further: reading internal files, reaching cloud metadata services, and pivoting deeper into the internal network.