The lab
here is how portswigger describes it
This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.
To solve the lab, use this functionality to cause an HTTP request to the public Burp Collaborator server.
this follows the back end system ssrf lab. those labs fetched a url and showed us the reply, so we could read the admin panel or scan by response. this one is blind the server still makes the request we ask for but never shows us the result, so we need a different way to prove it happened at all.
The idea#
blind ssrf is the same core bug, we get the server to make a request, but with no response coming back we cannot see where it went. the fix for not being able to see is the same trick as blind xxe, stop trying to read a reply and instead point the server at a machine we control and watch for it to make contact. burp collaborator is that machine, it hands us a unique subdomain and logs every dns lookup and http request anyone sends to it, so if we can steer the server's request to our collaborator subdomain, the hit shows up in our logs and proves the ssrf
the injection point here is not a url parameter but the Referer header. the site runs analytics software that, when a product page loads, goes and fetches whatever url is sitting in the Referer header of the request. that is a request the server makes to an address we control just by setting a header so it is ssrf, and we simply set that header to our collaborator url.
Step 1 - Send product request to repeater#
we visit a product page and send that request to burp repeater so we can edit and resend it freely.

Step 2 - Set the Referer header to a collaborator url#
in burp we open the collaborator tab, copy subdomain and set the request's Referer header to it.
Referer: http://your-collaborator-subdomain/
when we send this, the analytics software reads the Referer, treats it as a url to fetch, and makes the server issue a request to our collaborator subdomain. we do not see anything useful come back in the response, which is exactly what blind means, the proof is somewhere else.
Step 3 - Confirm the hit in collaborator#
we switch to the collaborator tab and poll, and there are the interactions from the lab server, a dns lookup for our subdomain followed by an http request.

that incoming request is the server fetching our url, which is the out of band signal that the blind ssrf is real

with this, we solved the lab!
