Blind Server Side Request Forgery

A Portswigger lab

We have already looked at Server-Side Request Forgery (SSRF) and found that exploitation usually relied on one key advantage: visibility; the attacker could see the server’s response reflected back in the client application

Blind SSRF changes the rules entirely.

With blind SSRF, you can still control where the server sends a request — but you never see the response. This raises an important question: If there’s no response, how do we know the application is vulnerable at all?

• Whilst we can control the destination of the request and the server still makes the request we get no direct feedback so all evidence of exploitation is indirect

Because of this, blind SSRF must be tested using out-of-band techniques.

Seeing in the Dark: Using Burp Collaborator

To test blind SSRF, we need a way to observe server-side behavior without relying on application responses. This is where Burp Collaborator becomes invaluable.

Burp Collaborator allows you to generate unique payloads and monitor for:

• DNS lookups
• HTTP requests
• Other network interactions

In a sense, Burp Collaborator makes us less blind

If you haven’t used Collborator before, try this guide: *https://appsec.guide/docs/web/burp/guide/manual-work/collaborator/*

What Does Success Look Like?

In a blind SSRF scenario:

• The back-end server attempts to connect to your Collaborator domain
• The request may be partially blocked by firewalls
• You may only see DNS lookups rather than full HTTP requests

Even a single DNS lookup can be enough to confirm SSRF, because it proves the server attempted to resolve and connect to a destination you control

Blind SSRF remains difficult though because the response from the back-end generally is not in the http request reaching Collaborator so there is an element of inference to looking for issues

The referrer header in a request is often used to track a request originated from, this data is often captured for analytics (SEO etc) and the sites in the referrer header are often visited for analytics systems to scrape, this is a common way to find a potential blind SSRF

Portswigger lab — 4

Lets have a look at a blind SSRF in action using the lab

Here, we see a standard web request being made to the lab application

Note the referrer header, then send this to the Burp repeater and change the referrer by right click on the header value and clicking “Insert Collaborator Payload”

We haven’t changed anything else on the request, the app will still behave as expected, but if there is potential for SSRF, we will see evidence in the Colloborator that the application back-end has processed the request and reached out to the referrer site

Send the request and after a few moments look in the Burp Collaborator tab

Here we can see two DNS lookups and a http request has been made as a result of the referrer change we made and the lab is solved

Detecting blind SSRF is only the first step, the difficult part of using that knowledge and crafting a payload now begins, but for some, the existence of it is enough…

Read an example of one found in a bug bounty here: https://shahjerry33.medium.com/blind-ssrf-the-hide-seek-game-da9d0ecef2fb