Now, it's very important
to understand the difference
between open redirect vulnerabilities
and server-side request forgery.
In an open redirect vulnerability,
the result is the user is gonna make a request
to the evil website specified in the malicious URL.
Whereas in an SSRF or a server-side request forgery,
the target web server is gonna make the request
to the other server, assuming the evil server
or any other kind of server.
So what's happening in an open redirect vulnerability?
We're sending a forged request
to the target vulnerable website with a URL.
And as a result, the target website
is actually sending a response back to the user,
telling the web browser to load the website we specified.
Now, I have the load here just in red
because there are a number of ways where a web server
can tell a web browser to load a different website.
So what's causing the web browser
to load the specified website
is the response that is coming back
from the target website as a result of the initial request
that the user sends with the URL specified.
Therefore, to have a better understanding
of this flow and how this is working,
a good idea is to come back to Burp
and enable the responses.
So we're gonna go to options
and click on intercept responses, we covered this before.
So that we understand what exactly is being sent
in this response that is causing the web browser
to load a completely different website.
So, let's go back to Burp,
and let's go back to the interceptor.
I'm gonna keep it off for now because I just wanna go back
to the original website before I exploit it.
We're gonna change this to return URL.
I'm gonna copy it so I can load it easily in the future.
I'm gonna turn on the interceptor,
and we're gonna hit Enter to load it.
And as you can see, the initial request is here.
It's a get request to the go file.
The return URL parameter is set to google.com,
to what we specified.
So, so far so good.
So this is this request right here, going to the server.
So that is fine.
We're gonna forward it.
And as a result, we're getting a response.
This response is coming from the target website
that we're exploiting.
And as a result, if you look in here,
you can see that it's specifying the location header.
And it's setting that to the URL that we specified
in our exploit, which is google.com.
And for some reason, it's appending #type=0.
So we actually never specified this in our payload.
We never specified that in here.
But for some reason in the response
it's being appended to the specified URL.
Now, because we see an equal sign,
this means that this is another parameter that we can test,
and therefore we should carry out more tests
by submitting the type parameter to the URL in here.
Now, if we stop the interceptor,
you'll see that we will actually be redirected to google.com
but the #=0 is still being appended to the URL.
So this is actually something
that is being sent back to the user.
So the user is asking for google.com,
and the response, instead of it saying load google.com,
it's actually saying load google.com #type=0.
So this is another parameter
that we can test for other vulnerabilities.
And we can manipulate just to see
what impact it has on the result.
So, we're gonna go back and go back in here as well,
turn on the interceptor, load the same URL.
And instead of setting it to zero,
I'm just gonna set it to one.
So it's always good to make small changes.
Instead of starting to type text and starting to test
for all of the other vulnerabilities
that we know like XSS and all of that,
let's just keep it as simple as possible.
Let's just try to understand what this type parameter does.
And instead of its default value, which is zero,
we're just gonna set it to one.
I'm gonna hit Enter,
and we're gonna see the initial request.
There's nothing strange about that.
And here is our type parameter being appended to it,
so that's good.
What we're interested in is the response.
So we're gonna forward, and we got our response now.
And this time, as you can see,
the response is a bit different.
So this time in the response
we actually have some JavaScript.
So changing the value for the type parameter in here
resulted in this change in the response.
So initially we actually had location header
followed by google.com.
But this time we actually have this script,
and the URL that we're specifying
is actually being placed in here.
So, whatever value we're putting in here
after the URL is being put in here
inside the two quotation marks which is inside a script tag.
So if we can break outside of this quotation mark,
we will be able to execute JavaScript.
But if you look closer just for one more second,
you will notice that this is specifying a href.
And we covered earlier in the XSS section
that inside href tags, we can actually inject JavaScript
without even having to escape anything,
without even having to close anything.
And as I mentioned before, it's always best
to try to keep our changes as small as possible,
because that way we have higher chances
of injecting code or exploiting vulnerabilities.
So instead of trying to exit this quotation mark
and then injecting code in here,
I'm gonna try to inject code within this
because we already have a href.
And we know that we can do that by typing JavaScript:
followed by the JavaScript that we want to run.
And in this case, it's alert two.
I'm gonna keep the type equals one,
because we know if we set it to zero,
the method is gonna be set to header,
and we won't even have this script right here.
So I'm keeping the type to one so that my code in here,
the JavaScript alert will actually be placed
inside this quotation mark.
And because this is inside the href,
my JavaScript will hopefully be executed.
So, I'm actually gonna drop this,
and I'm gonna paste the exploit that I just created,
and I'm gonna hit Enter.
And I'm gonna turn off my interceptor
'cause I want the result to go ahead.
And as you can see, we have our first request,
so that is fine.
We're gonna click on forward.
And here is the response that is coming back to the browser.
And as you can see, my code is being injected in here.
But literally just looking at the code, we can see
that this is not gonna work because as you can see
we have our JavaScript in here.
So that is fine and that is perfect, and it should work.
But the problem is we have these values being appended
to it at the end.
But these values are not JavaScript,
and therefore they will probably break my code.
But let's forward it and see what happens.
And as you can see, it didn't work.
So again, as mentioned earlier,
when we have values that are being appended
to our code that we don't like, what we do is
we put a semicolon to finish a JavaScript statement,
because that's the way that JavaScript works.
And we put two forward slashes
to comment the rest of the code,
so that anything that follows the exploit
that I just added will be treated as a comment
and will be ignored.
So we're gonna hit Enter again.
That's the first request.
We're gonna forward it, it's fine.
That's our second request.
And as you can see,
we have this being injected in the href.
This is normal JavaScript code, so it should work.
And anything that comes after it, which is this part
is gonna be ignored because it is preceded
with the two forward slashes, which will set it
as a comment, basically telling the browser to ignore it.
So let's forward this, and perfect.
As you can see, we got our alert message
executed on the target.
So now we have discovered a reflected XSS
in this target website in the go.php file.
So a lot of people would've left this
once they discovered the open redirect vulnerability,
because that is an actual vulnerability
and it is an actual ball, and you will get a bounty on it.
But as you can see, if you spend a little bit more time
trying to properly understand the flow
and exchange of information that is happening
between the client and the server, as you can see,
we managed to discover a very dangerous reflected XSS.
And in this case you have actually discovered
two books instead of one.