Introduction
Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.
The crucial point is that the server makes the request, not the attacker directly. That means the request inherits the server's network position, trust relationships, and access to internal-only destinations.
In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.
In this lab, you will interact with a simulated vulnerable web application. You will learn how to identify the SSRF vulnerability, observe how basic security filters attempt to block malicious requests, bypass those filters, and ultimately extract sensitive internal data and simulated cloud metadata. To keep the exercise compatible with shared lab environments, the simulated metadata service uses a non-privileged high port instead of port 80.
Identify URL Parameters
In this step, you will learn how to identify potential SSRF vulnerabilities by looking for application features that fetch data from external URLs.
Many web applications need to fetch resources from other servers. For example, an application might fetch a profile picture from a social media site or retrieve data from a third-party API. If the application takes a URL as user input and fetches it without proper validation, it may be vulnerable to SSRF.
This is why SSRF often appears in otherwise legitimate "URL fetch" features. The dangerous behavior is hidden inside a workflow that looks normal from a product perspective.
A vulnerable web application has been started for you on port 8080. This application has an endpoint /check that accepts a url parameter. It is designed to check the status of external websites.
You can test this functionality by asking the application to fetch a benign external website, such as http://example.com. Use the curl command in your terminal to send an HTTP GET request to the vulnerable application. If curl is new to you, think of it as a simple command-line web browser that sends requests and prints the server's response in the terminal.
curl "http://localhost:8080/check?url=http://example.com"
When you execute this command, the vulnerable application running on port 8080 receives your request, extracts the url parameter, and makes its own HTTP request to http://example.com. It then returns the HTML response back to you.
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
By observing that the server successfully fetched and returned the content of the requested URL, you have confirmed that the url parameter is actively being processed and used to make server-side requests. This is the first indicator of an SSRF vulnerability.
Test SSRF against Localhost (127.0.0.1)
In this step, you will attempt to exploit the SSRF vulnerability to access an internal service running on the server.
The primary danger of SSRF is that the server making the request often has a privileged position on the network. It can access internal services that are not exposed to the public internet. In our scenario, there is an internal admin panel running on port 5000. This admin panel is bound to 127.0.0.1 (localhost), meaning it can only be accessed from the server itself, not from another machine. You can think of 127.0.0.1 as the computer talking to itself.
As an attacker, you can use the SSRF vulnerability on port 8080 to trick the server into accessing the admin panel on port 5000 on your behalf.
Attempt to access the internal admin panel by passing its local URL to the vulnerable /check endpoint.
curl "http://localhost:8080/check?url=http://127.0.0.1:5000/admin"
When you run this command, you will notice that the request does not succeed. Instead, you receive an error message.
Error: Localhost access is blocked by WAF!
Developers often implement Web Application Firewalls (WAF) or input filters to prevent SSRF attacks. In this case, the application checks if the provided URL contains the string 127.0.0.1 or localhost. Because your input matched this filter, the application blocked the request.
Simple string filters are fragile because network destinations have multiple equivalent representations. Defenders need validation that understands canonical network meaning, not just literal text.
Understanding how the application filters input is a crucial step in exploiting SSRF, as it tells you what restrictions you need to bypass.
Bypass Input Filters
In this step, you will learn how to bypass the basic input filter you encountered in the previous step.
Bypass techniques work here because URL parsing, hostname resolution, and input filtering are not always using the same interpretation rules.
Input filters that rely on simple string matching (like blocking 127.0.0.1) are often flawed because IP addresses can be represented in multiple ways. The operating system's network stack will still resolve these alternative representations to the same destination, but the application's text filter might fail to recognize them.
Here are a few common ways to represent the localhost IP address (127.0.0.1) that might bypass a poorly implemented filter. You can use a shortened IP like 127.1, a decimal IP such as 2130706433, an octal IP like 0177.000.000.001, or a hexadecimal IP like 0x7f000001.
Since the application only blocks the exact strings 127.0.0.1 and localhost, you can use the shortened IP representation 127.1 to bypass the filter and access the internal admin panel.
Execute the following command to test the bypass technique:
curl "http://localhost:8080/check?url=http://127.1:5000/admin"
Because 127.1 does not match the blocked strings, the application allows the request to proceed. The server's network stack resolves 127.1 to 127.0.0.1 and successfully fetches the internal admin page.
Welcome to the Internal Admin Panel. Secret Key: SSRF_ADMIN_SUCCESS
You have successfully bypassed the input filter and exploited the SSRF vulnerability to access a restricted internal service.
Access Internal Metadata
In this step, you will use the SSRF vulnerability to access sensitive cloud metadata.
When applications are hosted in cloud environments (like AWS, Google Cloud, or Azure), they often have access to a special, non-routable IP address: 169.254.169.254. This address hosts the Instance Metadata Service (IMDS), which provides information about the running cloud instance, including highly sensitive temporary IAM (Identity and Access Management) credentials. "Non-routable" means the address is intended for local cloud infrastructure rather than for general public internet access.
If an attacker finds an SSRF vulnerability in a cloud-hosted application, querying this metadata endpoint is often their primary goal, as it can lead to full compromise of the cloud environment.
In this lab environment, a simulated cloud metadata service is running on 169.254.169.254:8000. The real cloud metadata service commonly uses port 80, but this lab intentionally uses port 8000 so the service can start without special privileges and without conflicting with other software. First, use the SSRF vulnerability to list the available metadata directories.
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/"
The server will fetch the metadata directory listing and return it to you.
iam/security-credentials/admin-role
The output reveals an IAM role named admin-role. You can now append this path to your SSRF payload to extract the actual security credentials associated with this role.
Execute the following command to retrieve the sensitive credentials:
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/iam/security-credentials/admin-role"
The simulated metadata service will return the JSON-formatted credentials.
{"AccessKeyId":"AKIAIOSFODNN7EXAMPLE","SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}
If this request does not return data in your environment, briefly check /tmp/meta.log and confirm that a service is listening on 169.254.169.254:8000.
By successfully extracting these credentials, you have demonstrated the severe impact of an SSRF vulnerability in a cloud environment.
Summary
In this lab, you successfully explored and exploited a Server-Side Request Forgery (SSRF) vulnerability. You learned how to identify vulnerable URL parameters by observing server-side fetching behavior. You then encountered a basic input filter designed to block local access and successfully bypassed it using alternative IP address representations. Finally, you demonstrated the critical impact of SSRF by extracting sensitive simulated cloud metadata credentials. Understanding these techniques is essential for both identifying vulnerabilities during security assessments and implementing robust defenses in web applications.
