skip to Main Content
Server-side Request Forgery – Open Door To Your Internal Services

Server-side Request Forgery – Open door to Your internal services

Server-side Request Forgery – Open door to Your internal service

Picture source:

Server-side request forgery aka SSRF, is a vulnerability that enables an attacker to use a vulnerable server as a proxy to make HTTP requests on behalf of the attacker. SSRF’s are regularly used to target internal services that are behind firewall and not exposed to the public directly. Vulnerable server could allow mapping the internal network or services and possibly give access to administrative functionality. Good example of such vulnerability could be the Microsoft Exchange Server CVE-2021-26855 aka ProxyLogon

What can we do with SSRF?

Server-side request forgery can be made possible when a web application is making a request and attacker has partial or full control over request parameter(s). As Burp Suite is a common tool in penetration testing community, examples from their SSRF lab are used within this blog post to show how the attack works. Attack diagram representing the flow of the attack is taken from OWASP cheat sheet series, what is another very good resource for penetration testers.


SSRF attack diagram from OWASP:

Example request:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118


As we can see, stockApi parameter is using full URL as a value to fetch some data. This could be abused if application has no protection against it.

Malicious request:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118


With this request we are trying to get the internal admin page content. By fetching this page, malicious user could see the admin panel because request comes from server itself and not from outside.

SSRF is not limited to HTTP protocol!

HTTP requests are the most common examples of SSRF, but it is not limited to that as the application itself does the second request.  It could be possible to use different protocols (such as FTP, SSH, SMTP, SMB, etc.) or schemes (such as file://, gopher://, dict://, php://, jar://, tftp://, sftp//, ldap// etc.). These are highly dependent on the application under testing.  Additionally, in case there is XML external entity injection vulnerability in the application, it is highly likely that it could be turned into SSRF  attack.

Based on these examples, malicious request could also look like this:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118


If application would be vulnerable to this attack, content of the passwd file would be returned in the response.  But this could be used to get any other file, and this could mean revealing secrets on the server or used by the application. For example AWS keys and internal data.

It could be possible to map internal IP-s and services on these:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118


This request might return SSH service banner and with that knowledge of what library is in use. This might open up new attack vector, example from the older days would be ShellShock.

What is blind SSRF attack?

Blind SSRF attack is when backend server does the requests attacker issues, but response is not sent to the frontend. This still can be detected when attacker monitors networks requests to domain they control. In penetration tests one of the ways to test this would be with Burp Collaborator plugin and by using Burp Collaborator client to generate a new domain.

Example of such case from blind SSRF lab:

GET /product?productId=2 HTTP/1.1


And when polling information from Burp Collaborator client, it is possible to see that HTTPS request to that domain was done.

How SSRF vulnerabilities can be dangerous?

SSRF attacks could lead to data exfiltration or even worse, system level access to affected service. Aforementioned ProxyLogon vulnerability is good example for this from the Microsoft Exchange SSRF vulnerability (CVE-2021–26855), what allowed attacker to send arbitrary HTTP requests with the highest privileges on internal services. It made very easy to download any user emails by just knowing victims email address. Other use case would have been uploading a web shell to vulnerable server. For that SSRF attack would have been combined with CVE-2021–26858 or CVE-2021–27065 to write a file onto the server.  Good review of the attack against Exchange severs could be read from here: Hunting Down MS Exchange Attacks. Part 1. ProxyLogon (CVE-2021–26855, 26858, 27065, 26857)

There are many examples how SSRF has been used against well-known services and companies, one good awarded bug bounty is from Ezequiel Pereira and how he found remote code execution through SSRF in Google Cloud Deployment Manager and was awarded $164,674 for this bug. For that same finding there is very good video also.


Unfortunately, there is no universal solution how to fix this. Good start would be by whitelisting IP addresses and DNS names what the application is allowed to access. Have strong input validation throughout the application and do not allow the application to trust any input. If possible, whitelist protocols and schemas used by the application so no other could be used. Additionally, have a generic error message for exceptions and define “last resort” error message,  in case all other exception handling fail.


Server-side request forgery attacks make use of parameters where full or partial URL is used or can be used. This could be dangerous vulnerability to have on Your application. In recent years it has had more attention because as widely used systems have been affected, like referenced throughout this blog post. Protect Your application by having strong input validation and whitelisting. Get Your application tested by professionals!


Buckle Up

Get in touch to find out more about our services​ and setup meeting with our cybersecurity advisory.