let's talk about discovering blind srf vulnerabilities.
So as we mentioned earlier, the main problem with blind SSR vulnerabilities
is that it does not send a response.
So the first request will be executed by the vulnerable web application.
It will be sent to whatever destination we're asking it to go to.
But there is no response sent back in here and therefore there
is no way for us to know that our payload got executed
or maybe there is
what we can do. We could send a forest request
to get the vulnerable web server hosting the vulnerable web application
to send a request to a server that I control as the hacker.
And then I can look at the logs of my server
and if I see a request coming from this web server,
then I will know that I managed to hijack this web server and get it
to send requests to another web server that is not supposed to send requests to.
And then from there we'll talk about exploitation.
But like I said, we'll cover that in the next lecture.
So let's go ahead and have an example of this.
So we have a lab right here and as you can see this lab is rated expert.
So we're just gonna run it in a new tab.
And as usual, we always say that you want to test this website,
test every single functionality of it, use it as a normal user and see how it works.
And once you're done with this we're gonna turn on our interceptor
and intercept the request and discover
vulnerabilities and possibly exploit them.
So let's click on a product and we have the request that is sent in here.
And as usual you want to go again and test all the parameters that you have.
But we're not going to be doing that because I've already tested that.
And what we wanna do is we wanna play with the referral value that we have in here.
So as you can see,
we have a website that is being sent in here as the value for the referral.
And as shown previously when you see full links like this being sent as a request,
you want to play with them and test for
open redirect vulnerabilities and for server side request forgeries.
And we covered a number of ways of discovering server side request forgeries.
I'm not going to show it right now because I don't want to waste your time,
but none of them will appear to work.
But they're actually working.
They're not going to appear like it's working because
this is an example of a blind SSR vulnerability.
Therefore when you're gonna send it a request like this, it's actually gonna work.
It's gonna send it to whatever you want to send it,
but it's not going to send you a response.
Therefore we're going to have to modify that to a location of a server that we own.
So you could start any cloud server on amazon or
node and put the address for that server in here.
Or you could use the collaborator feature of the burp suite.
Now the collaborator feature is only available in the pro version of Burp suite.
So if you don't want to pay for the pro version,
you're going to have to set up your own cloud instance
and for this lab for this particular lab,
they actually have it restricted to only work
with Burp collaborator because they do I want
you to be using their server to send requests to any server on the internet.
So it's understandable.
That's why if you want to complete the stab you will have to get the collaborator.
But the collaborator is not necessary for discovering blind srf
vulnerabilities you could use your own cloud instance on the internet
to use the Burp collaborator. We're gonna go to the burp menu
and we're gonna run collaborator client
and it's asking you for the number of payloads to generate.
So we're just gonna set it to one.
We're going to click on copy to clipboard and this
will copy the payload U R L in my clipboard.
So if I send their quest to this payload.
So as you can see we have a payload now that's created by bourbon collaborator.
If I hit enter nothing is gonna load just the value of the payload
but if we go back in here and click on paul. Now
you will see the requests that were sent to this payload and
it will even show you the I P that sent this request.
So this is similar to you put in an address of a server that you created
on the cloud and then reading the logs to see if it got any requests.
So it's just an easier way of doing this.
That's the whole point of the burp collaborator. It gives you a U. R. L.
That you could submit anywhere when you're testing for any kind of vulnerability.
And then you can simply click on paul now to see if that U. R. L. Received any requests.
So now what we're gonna do, we're gonna actually clear all of this
and we're gonna go back to the request that
we intercepted and we're gonna remove all of this
and I'm gonna paste my burp collaborator payload that I just got.
So all we're doing instead of testing for
local host admin or testing for internal services,
we're actually putting the link for our burp collaborator U R.
L.
And then if a request is sent to this,
I'll be able to see it in my
collaborator because that's all what the collaborator does.
So we're going to forward this
Forward it again and let's bring back my collaborator
and I'm gonna click on Paul now or it automatically
did a poll because it does it every 60 seconds.
And as you can see we actually got a request.
So this indicates that this web application
is vulnerable to a server side request forgery
because we sent it a forged request to send another request to my web server.
And then I checked the logs of my web server and noticed that this web
application actually did fulfill my forged request
and send the request to the Forest server
and pen tests.
And in many bug bounty programs,
it's actually enough to simply show them that you managed to get the server to
send the request to another server to display
that there is a blind SSR vulnerability.
But in some cases you have to display impact.
You have to show impact and therefore you have to
take it another step and try to exploit this vulnerability.