SSRF Blog Banner

Hello, I hope you and your families are healthy and safe during this pandemic. Stay strong mentally, and we will fight COVID-19 together. Let’s start learning to make our day productive and fun.

This blog teaches you about SSRFs (Server Side Request Forgery) - a very popular web security vulnerability.


What is SSRF?

SSRF stands for server-side request forgery. It is one of the most popular web security vulnerabilities exploited by hackers and security researchers.

It is a security vulnerability where an attacker can abuse the available functionalities in a server-side application to access internal server files, resources leading to potentially sensitive information disclosure.

How does it work?

In modern-day applications, it is common to find functionalities that communicate with internal servers, access resources, etc.

If any functionality is vulnerable to SSRF attacks then an attacker can manipulate the address of the requested resource and get access to it easily.

What causes SSRF?

To access resources in a machine, we always need to specify a unique address. It can be an HTTP URL or simply a file path. The outcome is based upon our input we give as the address.

There are instances where an application trusts the server itself for requesting, modifying resources and in that case, if there is a request having the address of the needed resource, an attacker can modify it to make the application access resources other than what is needed in the context of that user session.

The same can be done if the application has trust built over any external backend server i.e. any server that is not the one where the application is hosted at.

Let’s understand it better through some visuals: There are functionalities where the application is supposed to be communicating with a server and access resources.

  • A normal scenario where a user is fetching information from an API server:

Intended Flow

We can see that the web application requests for the resource from an external server and present the data to the user.

  • A scenario where an attacker modifies the address of the requested resource (SSRF):

SSRF exploitation

We can see that the attacker modified the GET parameter resource and put in the address of the localhost server where he knows that creds.txt is available. As the server trusts the web application (because of the same IP address), it gave aways the data creds.txt easily.

The server assumed that the request to access creds.txt was coming from the same machine itself and not by any external user (the attacker).

In the above scenario of SSRF exploitation, the output of the requested resource was directly presented to the attacker through the web application. However, there are other types of SSRF scenarios where this might not be the case. Let’s understand the types of server-side request forgery now.

Types of SSRF

Non-Blind SSRF: This is a type of SSRF where an application fetches the requested resource and directly presents it on the front end. The whole output is clearly visible to the user/attacker.

Blind SSRF: This is an interesting and very common type of SSRF where the HTTP request for requesting resources is made by the server but the output isn’t visible on the frontend. In simple words, the resource is requested by the server but not displayed to the user/attacker. There are certain ways of exploiting this type of SSRF vulnerabilities and we will cover them further in this blog.

Semi-blind SSRF: In this type of SSRF, a resource is requested but the complete output isn’t visible to the user but instead it can be file metadata, parts of the file, complete file path in the form of stack trace errors, and more.

This is called semi blind because the data is partially available, unlike blind SSRF where nothing is visible on the frontend. To exploit semi-blind SSRF, similar ways of exploiting blind SSRFs can be used.


We will now cover the exploitation of the different types of SSRF cases explained above. Keep in mind that there can be unique methods of exploiting SSRF because the behavior of the application matters a lot while exploiting and validating security issues so a straightforward method may not always work.

Non-Blind SSRF

The exploitation of a regular non-blind SSRF is simple as we expect the output to be displayed directly on our screens.

It is usually when an application sends a request to fetch a resource located in the same server itself or sometimes inside external backend servers, IP addresses and virtual hostnames can be used by the web application to reach out to the external servers. If we know the address of the resource we want to access, we can use that URL/path to make the application fetch the resource and simply display it to us on the frontend.

A common scenario here is when an application is hosted on AWS or Google Cloud or other cloud services then there are link-local addresses provided by the cloud service provider to fetch internal metadata. In the case of AWS, the address is and if an attacker can hit this target from an SSRF vulnerable application hosted on AWS, sensitive information can be exposed.

List of Cloud Metadata fetching endpoints -

Keep in mind that there are cases where an application blocks certain protocols, keywords so you might require bypassing some blacklists, and bypassing WAFs is a whole different topic. (I might write another blog on that one 😉)

Where to look for non-blind SSRFs?

Non-blind SSRFs are common in PDF generators, HTML-to-PDF converters as we can use HTML code to create an iframe with the contents of an internally located file.

For hunting SSRFs in web applications, enumerate all the endpoints well because you might get different GET/POST parameters with URL or pathnames and they are usually the most common candidates for testing SSRF vulnerabilities.

An endpoint with GET parameters like ?file= or ?resource= are more likely to be vulnerable to SSRF as the parameter name suggests a potential value of file paths and URLs. Modifying the value to internally located filenames or even external hosts can help in testing SSRFs.

Blind SSRF

Similar to non-blind SSRFs, we should look for endpoints where there is any type of URL or file path we can modify.

In blind SSRF, an application takes a resource address and tries to send a request to it. We can host a server we can control and use the address of it to try exploiting blind SSRFs.

If there’s an endpoint that loads images from external URLs then we can start a local server and use the address as the image URL and if the application tries to load the image from our entered URL, we should see an HTTP request in the logs of the server we control.

How to exploit it? The way to exploit blind SSRF isn’t clear. There are many different methods we can try to gain something impactful out of blind SSRFs.

One way to gain something meaningful: A vulnerable application can send a request to external hosts that we control and we can read the request headers inside our log files to gain more information about the internal infrastructure. With this method, internal IP addresses can be exposed and used for further exploitation.

The impact of blind SSRFs is usually dependent on our abilities to chain different issues together. Forming a great exploit chain can help gain something impactful out of a blind SSRF. The deployed infrastructure plays a huge role in it.

There are cases where blind SSRFs are escalated to remote code executions by injecting command injection payloads in remote URLs e.g.$(whoami)

I found an awesome GitHub repository with precious knowledge on “Blind SSRF Chains” -

Cross-Site Port Attack (XSPA)

Another great way to gain something impactful out of blind SSRFs is by an XSPA attack. It consists of entering the address of am internal hostname from the intranet or the web server itself so that the vulnerable application hits the target and we can determine the availability based upon the response timing or error messages.

Let’s say we enter the IP address with different ports ranging from 8000-9000 in a parameter vulnerable to Blind-SSRF. If the usual response time is 1500ms on almost all the ports but the response from port 8443 is unusually delayed (e.g. 3000ms) then it’s often an indication that internal port 8443 is open and the rest of the ports are closed as 8443 took the longest time to respond.

Using banners, error messages, response timings, we can enumerate the infrastructure specifics, and that’s how you take advantage of blind SSRFs.

Keep in mind that not all applications that send the request to internal/external servers are exploitable, many endpoints are intended to send requests for a smooth experience and different features. To protect such endpoints from being exploited, developers use a proxy or isolated servers just to make those requests and even if an attacker gets information about those proxy servers like the IP address, it’s usually meaningless.

Semi-blind SSRF

It is almost similar to blind SSRF but in this type, the information revealed won’t be the complete data from the fetched resource. Instead, you might just get the file path in the server or get clues from the response if the file is available in the server or not. Exploiting this vulnerability can be done by enumerating the availability of internal files and maybe fetching some meta-data. All of it is totally dependent on the nature of the application.

Mitigation Tips

There are different ways of mitigating SSRFs. Developers often use regular expressions and blacklists to filter out arbitrary input but there are ways to bypass them so it’s not a great idea to rely on blacklists.

Some better mitigation techniques are as follows:

  1. Disabling unnecessary URL schemas - SSRFs aren’t just about sending HTTP requests to internal/external hosts via the vulnerable application. Many different protocols can be used to fetch data from different kinds of infrastructure set-ups. Most common ones are dict://, gopher://, ftp://, file://. Disabling unnecessary protocols can help by reducing the attack surface for the attackers to fetch data from.

  2. Response Validation - The response fetched from the HTTP requests made by the application shouldn’t be served to the user directly. There should be a validation process of data in action so only the expected input and output work.

  3. Authentication - Authentication inside the local network can be used to make things harder for the attacker,

  4. Proxy Servers - Proxy servers can be used to make requests and fetch resources, the server should be isolated and shouldn’t have access to the critical infrastructure and data.


Server-side request forgery is one of the most interesting and popular web security vulnerabilities. I highly recommend you to learn more of it if you’re into application security. Here are some good resources that can help with the process. Enjoy!

I hope you enjoyed this blog! Feel free to message me on my socials for feedback/suggestions. Contact Me

Note: You can Buy Me A Coffee if you like my content! All of the money collected within May will be used to help COVID-19 patients in India.

Subscribe to my weekly newsletter for more cybersecurity resources and content -

Thank you for reading!

Back to Top